OSDev.org

Nelson wrote: I'd preferr the 99% doc and 1% code.

But before writing the doc is better to write the code to have
something to write about

Dex4u wrote: FASM assembler and see how easy it is to port, 3 hours to port it to Dex4u

Do you mean 3 hours after writting all the required libraries and clue code?
It took 3 days to me ,+ 10 days to implement support to elf relocatable files, but yes, is very easy compared to other
programs.
Those days i'm porting some code written in 'C'
to my OS , first i compile to elf format with djgpp and second i add the glue code, is pretty easy for small programs ,and i thing that perhaps i could do the same with some linux drivers
if i?m able to understand how to compile them, because linux
sources are not as easy as Fasm sources

@octavio, It took me about 3 hours to get it up and running enough, assembly a simple "hello world" program, to finish about a week, working a couple of hours a day.
But it took 3 weeks to port a Dos game to my os, that i wrote my self.
I find linux driver the only source for info for most drivers.
Most of the hardware ( that needs drivers ) i have bought recently, has come with C code for linux.

But before writing the doc is better to write the code to have
something to write about

I agree 100% with this, how can you write about something you have not coded, what if you write a doc and find your theory did not work, even when coding you modify you code all the time, that why i usually only add comments when finished.

Solar wrote:

Dex wrote: I am saying that it would be easier to make drivers, that are OS independent or just need linking into your OS, than implement UDI.

Uh-huh. So you think you are able to write "OS independent drivers" without an abstraction layer for the differences in e.g. interrupt handling, PCI bus handling, memory handling, data structures, etc. etc.? "Just linking into my OS", without having an idea of what my OS is like? You don't even know which binary file format other people's OS' are using!

You need to all agree on a minimum functions for each type of driver...

Yep. But how do we do this without triggering your documentation allergy?

I will make a driver for this card, that is OS independent, to show proof of concept.

In the interest of *somebody* telling me what an idiot I am,

Yeah, I'm really looking forward to it. </sarcasm>

here is your abstraction layer.

[me=Crazed123]keeps trying to get somebody to critique or something... [/me]

Dex wrote: @octavio, It took me about 3 hours to get it up and running enough, assembly a simple "hello world" program, to finish about a week, working a couple of hours a day.
But it took 3 weeks to port a Dos game to my os, that i wrote my self.
I find linux driver the only source for info for most drivers.
Most of the hardware ( that needs drivers ) i have bought recently, has come with C code for linux.

But before writing the doc is better to write the code to have
something to write about

I agree 100% with this, how can you write about something you have not coded, what if you write a doc and find your theory did not work, even when coding you modify you code all the time, that why i usually only add comments when finished.

It's a given you're going to have to write code to document it, theres a difference however if you actually release the code, the doc, or both.

If anyone were to slap me just code I don't consider that any proof of concept without proper documentation for it. Actually I wouldn't even begin to examin the code and just garbage it, Id personally take it that the coder has just built a driver around his OS more then a universal one. Sure it will be easy to port something in one's OS but I'm quite sure its not always the case in another OS design. The biggest conflict I'm seeing has to do if device drivers are ment to be in user drivers or kernel space drivers, and security of the kernel it is design around (mainly I/O, memory and perhaps threads if its multi-tasking). But this is me talking from the back seat of things.

Dex wrote: ...how can you write about something you have not coded, what if you write a doc and find your theory did not work...

And that is why I am making a living out of software development, and that's why your OS doesn't even document its own basic functions and data structures.

[me=Solar]throws his hands up in the air and stops discussing things with 1337 kidz c0d3rz.[/me]

Dex wrote: I see your a user of Dex4u OS. nice .

Nope, not a user. But after one of your rants about "code first, docs never", I couldn't help but have a look at your homepage / sources.

looking at this thread and wonder why there's been some much noise about it ? became it turned into one of our darkest flamewar. One flaming on persons rather than ideas[/i].

I don't think we need to keep track of what people have felt offending as a proof of how they react, so it's been moderated. period.

If you've got something to add about device drivers in new OS, you're welcome.

Quite some stuff going around here, eh?

Nah, I'm not interrested in flamefests. I 've got enough under the hood to deal with.

regarding "device driver compatibility in new OS:

You 'd need a set of functions in the kernel / the driver so the two of them can talk smoothly. you could of course strip this down to the bare minimum. Well. That's about it. Not thinking complicated but keeping stuff simple.

but what of cases, like usb or something, were there is no pre-wrote kernel functions?

cannot tell for sure before i've written myself a couple of USB drivers...

should be possible to map driver operations:

see: a harddisk behaves like a block device be it on IDE/SCSI/USB. Just how to talk to the device is different - but that's the task of the driver. Others just want to tell the driver: He, you, gimme two blocks of device 1 you're responsible for. Or: he, you, write these two blocks And here are the adresses of the data. Same goes for mouse, Keyboard and other stuff.

But that's /dev/brain rambling around. I have yet to design and implement usb stuff.

[ot]'ve had a math's colloquium two days ago. Imagine: integration, taylor series, linear differential equations of second order, function discussion with one really nasty term: e^x/x^2. And one de l'hospital. solved after at least 12 derivations due to all the sin & cos. It's good to be able to do the deriving & integrating stuff without thinking. Oh, & btw: wtf is Ljapunov? (guy that told about stability point for linear differential equation?)`Ah, I'll be happy if that result's not a T (like Troll)[/ot]

beyond infinity wrote: see: a harddisk behaves like a block device be it on IDE/SCSI/USB. Just how to talk to the device is different - but that's the task of the driver. Others just want to tell the driver: He, you, gimme two blocks of device 1 you're responsible for.

sure, that's how it'll work in e.g. windows or Linux (afaik). Know if you just ask "gimme two blocks from device 1" it may require the driver to do things that are too much related to the OS proper -- such as waiting for interrupts, etc.

So far, in clicker i've tried to break those things so that you rather say "prepare things to get me two blocks when you can" and the black-box driver says "okay, i'll do". It may enqueue some state (aouch, true: we'll need kernel interaction for that) and there's another function (invoked by interrupt handler most of the time) that will process this state when time comes.

It looks like i've underestimated some issues with the "black-box kernel" and "black-box driver", at least when it comes to asynchronous requests (mosts are).
Yet we can make it OS-agnostic by saying "you must provide two functions enqueue_state(), cancel_state() and dequeue_state() to the black-box driver so that it works properly."

That's a bit of a double-side "proxy" pattern where you abstract behaviour of the driver for the kernel and abstract the behaviour of the kernel for the driver. I'd get flamed to hell by LKM if i say that, but yes: i believe nvidia approach more than UDI or SNAP ... and yes, i challenge myself to run the nvidia driver within clicker. (i know: i'm insane)...

Pype.Clicker wrote: That's a bit of a double-side "proxy" pattern where you abstract behaviour of the driver for the kernel and abstract the behaviour of the kernel for the driver. I'd get flamed to hell by LKM if i say that, but yes: i believe nvidia approach more than UDI or SNAP ...

If they offered documentation for their closes source module's ABI, it'd would be almost perfect, IMO. But generally, I agree.

Pype.Clicker wrote: and yes, i challenge myself to run the nvidia driver within clicker. (i know: i'm insane)...

I thought about that too, but graphics are still something far far away in future for my own OS. Just out of interest, have you elaborated a bit on licensing issues for the closed source nvidia driver? I mean, is it legal or at least tolerated when you reverse engineer their ABI and implement your own glue code?

cheers Joe

<edit> this is now discussed in General, Off-Topic and Everything Else post "Reverse Engineering (legal issues)"</edit>