Device Driver Compatibility in new OS

[Pype.Clicker]

you could make the os-agnostic driver shipped binary if you want to. E.g. that'd just be a library of code suiting your CPU against which you link your glu code.

Things like "ac97_init", "ac97_reset" or maybe "ac97_dma_callback" to be invoked when some IRQ is to be taken, etc. I don't think there's a real need for "ac97_init" to be able to create a new interrupt handler, for instance, if you document that "OS should make sure that ac97_dma_callback will be called when device IRQ is triggered".

Routing interrupts etc. would remain under the management of the "core" OS. You read the documentation coming with ac97.a. you write ac97_myos.c, you compile. it works.

Same for buffers allocation, etc. and -- most important -- for communication with user-world (managing /dev/audio0 or whatever is the sole responsibility of the OS-specific part). If some program has written user-data on /dev/audio0, it's up to os-specific glu to make sure those data are available in kernel-land before invoking "ac97_write_data(&buffer)".

[Dex4u]

I agree with you PypeClicker, once you start coding drivers you see how little OS dependant code there needs to be.
I am making a RTL8139 driver for my OS and there only needs to be 4 function for ethernet driver to implement.
1. Probe
2. Reset
3. Poll
4. Transmit

[Candy]

I agree with you PypeClicker, once you start coding drivers you see how little OS dependant code there needs to be.
I am making a RTL8139 driver for my OS and there only needs to be 4 function for ethernet driver to implement.
1. Probe
2. Reset
3. Poll
4. Transmit

And I was wondering why you weren't receiving...

(yes I noticed the poll option)

[Dex4u]

Candy, Your assumption is right, the "Poll" is polling ethernet card for a received packet.

[Solar]

Uh-huh... I thought polling was more a thing out of the early eighties...

[Candy]

so you're going to spend so much time on polling that you keep up with 100mbits, even though it gives you interrupts when it's filled buffers / is out of buffers?

[Dex4u]

It just a name, how it is called is up to OS designer, but remember Dex4u is single-tasking, and even multi-tasking OS like MenuetOS poll rather than use int.
If in uses, we find it slow, we can easily change the way its called.
I am a great believer in getting something working, in the simplest way, then optimise for speed once its working reliably.

[Crazed123]

[me=Crazed123]reads carefully...[/me]

<issues type="bitterness">Wow, everyone actually has opinions on this topic. They just don't bother to show them when someone puts hands to coding. 93 views and not one reply?</issues>

Note: If this post sounds like me being an @$$, that's because I've been rather stressed today due to traveling. Expect manners tomorrow.

[GLneo]

Are you saying us OSdever's make a universal driver standard then make a NIC card driver and see if a few of our system can run it? Or is this thread moved to polling? If it?s building drivers I?d love to help.

[Dex4u]

As far as polling is concerned, i just answered the ? put to me.
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.
These would be more usefull to hobby OS Dev's, than 10's of MB of doc about a Uniform Driver Interface.
You need to all agree on a minimum functions for each type of driver, this does not mean you can not add more, but it means you could use the driver for what it was designed for.
My example was a ethernet card driver, function number 4
1. Probe
2. Reset
3. Poll
4. Transmit
I will make a driver for this card, that is OS independent, to show proof of concept.

[Pype.Clicker]

actually, i can think of a few reasons why a "poll" method like dex's is enviable in an "OS-agnostic" driver:
1. that means you're free to call "poll" in the interrupt handler of your own OS if your own OS supports interrupts... or to use it in a loop to do actual polling if you don't support interrupts (realtime OS, anyone ?)
2. That also means if you think there may be not one, but several packets pending (with some interrupts blocked), your OS driver can decide to call "poll" up to n times (where n is decided from the time quota you allow for handling the interrupt.
3. If you're in a microkernel approach, you may expect the interrupt to be delivered as a message and call poll() in usermode when the message is received.

Also, i assume "probe" is there to 'sense' if a packet has arrived or not (or does just poll() return a status indicating the interrupt was not for us ?)

Beside UDI, i've been messing with intel's "OS-abstraction library" for IXP drivers... and trust me when i say "messing". The resulting driver is a kind of mix of OSSL concepts, linux concepts, hardware-related considerations, etc. They fork obsolete 'tasklets' because they couldn't come with a suitable abstraction of semaphores within linux kernel (and keeping the drivers working with VxWorks or QNX).

Now there is at least one "OS abstraction" we need to provide: messages logging ...

[Solar]

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.

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

[Pype.Clicker]

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 before peek-and-poke-solar-vs-dex starts again ...

UDI and friends focus on delivering "drivers" that are functionnal. I think (and it sounds to me that dex's point of view might be close here) that parts of the driver that is device-specific could be extracted from the driver itself and exposed as a library of os-independent code.

Take PCI. once the device has been identified (os-specific) and the BARs have been read (os-specific) you could create vaddr-to-paddrs without help from device-specific knowledge, right ? all you just need to give to the driver then is pointers towards those vaddrs in the same order as the BARs are.

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

i guess if i manage to put the glu between your driver and clicker without a-priori coordination, that will even better demonstrate the concept

[Dex4u]

Yes i do believe i can make OS independent driver for rtl8139 ethernet card, so when its done, i am sure you will give it a good workout .
But as i stated and Clicker, some linking in will be needed in most cases, But by eg: calling poll from your int or loop, you give the designer of the OS, the choose to glu it into his OS, as best fits his/her OS design.
If you want a demo of concept, you must get the source to FASM assembler and see how easy it is to port, 3 hours to port it to Dex4u
and just like drivers you need OS dependent code to be linked in.
Eg: memory handling, open, close, read file, timers, print etc.
But these are all in a separate file, with a simple doc that tells you what each link needs.
Note: I am not against doc, but i like to see 50, 50 split, not 99% doc and 1% code.

[Warrior]

I'd preferr the 99% doc and 1% code. I'm not a big fan of plug-n-go drivers into a system, no sense of acomplishment.
I do think however providing interfaces for driver implementation, and then documentation for implementing the glue code is sufficient.

If we could do this would even a few drivers (already well documented ones even) we could start a trend in driver designs which would benefit the community. The goal I think isn't to necessarily make them just drop and run in multiple OSes, but to make them simple to port.