OSDev.org

UDI relies heavily on a micro-kernel design with messaging (IPC) as the only method to communicate between drivers, driver-app and driver-os. This is totally unacceptable for non-microkernel OSes.

Look at Intel's ACPICA as a very good example of how a complex interface should be implemented in an OS-independent manner. The document has no requiremens for IPC-functions, and clearly states the procedures that the OS needs to implement. The code is also highly portable and compiles with a 32-bit segmented memory model.

I would find AML-code for doing specific device-operations (setting video mode, NIC initialization, for instance) much more useful than a unified device interface requiring IPC.

rdos wrote:UDI relies heavily on a micro-kernel design with messaging (IPC) as the only method to communicate between drivers, driver-app and driver-os. This is totally unacceptable for non-microkernel OSes.

Could you please refrain from spreading FUD on subjects you obviously know too little about?

UDI has been successfully implemented on Solaris, OpenServer, UnixWare, XP/UX, Tru64, AIX, and Linux.

Please point out which one of those are microkernel designs, or how that "unacceptable relying on IPC" hampered the non-microkernel designs in the list above.

It's not called IPC in the UDI document, but rather "channels", but it is the same thing!

Take for instance a NIC interface. Broadly speaking, UDI specifices two IPC-channels for a NIC (input and output channel). That does not look like an effective interface given how a typical, fast NIC driver is coded for a typical Gigabit NIC.

1. The "input" channel is presumably used for packets that the NIC sends. A good network stack implementation should be zero copy, meaning that the message is not copied anywhere in the network-stack. My implementation of a NIC interface defines one procedure to allocate a network buffer (could be a ordinary memory block, or a buffer in the NIC device ring, it's up to the driver), and a send procedure. This guarantees that all NICs can be implemented as zero copy network stack if their buffer management is memory-based.

2. The "output" channel is presumably used for received packets from the network. In most (if not all) NIC drivers these packets start in an IRQ. My implementation provides a notification from the IRQ to the network stack. The network stack then would signal a NIC kernel thread, which reads packets. The NIC interface is required to implement poll, receive, and remove procedures on this side, and can implement a network-stack with zero-coppy that mostly does not run in IRQs. How UDI does this is hard to know based only on the network interface specification.

A "universal driver interface" should have defined a couple of essential C procedures that a NIC driver would be required to implement (for instance allocate_buffer, send, poll, receive, remove as above), and not a channel (IPC) based interface. An OS wanting the channel-based interface could add that itself, as it has no relevance for a functioning device-driver.

Bla, bla, bla.

You've read a paragraph in the UDI specs, go on "presuming" a bit here and there, and then of course you know enough to tell everyone that they did it wrong, and how it should have been done.

You are aware that UDI has been benchmarked? And that UDI drivers performed on par, sometimes even better, than native drivers?

The proof is in the pudding.

I read the whole NIC interface specification + skimmed through the basics.

DavidCooper wrote:It sounds as if my concerns about UDI possibly restricting the design of an OS may be totally misplaced, and certainly everything else I've heard about it leads me to think it is UDI that most people should be getting behind. It may be that UDI could become a bolt-on package to work as a modern (and much more advanced) BIOS replacement on machines which only boot using EFI, and the death of the BIOS might in itself trigger manufacturers into backing UDI once they no longer have to spend time on all the old legacy stuff.

I'm not sure what you think the connection is between firmware and driver interfaces. They are two independent things.

rrdos wrote:Look at Intel's ACPICA as a very good example of how a complex interface should be implemented in an OS-independent manner. The document has no requiremens for IPC-functions, and clearly states the procedures that the OS needs to implement. The code is also highly portable and compiles with a 32-bit segmented memory model.

Reminds me of UDI

rdos wrote:It's not called IPC in the UDI document, but rather "channels", but it is the same thing!

Hmm, this is where the problem comes from, you are misinterpreting the abstraction provided by channels. Do you only see one way to exchange control blocks? Your feedback will help me improve the Uniform Driver Interface article on the wiki.

Last but not least, the U in UDI stands for Uniform, not Universal---you made that mistake twice, which makes me think you didn't really study the specs carefully.

rdos wrote:I read the whole NIC interface specification + skimmed through the basics.

...and thought you understood enough of it to discourage other people from using it, when even reading the relevant Wikipedia article would have told you the reasons for their design decision:

UDI provided an encapsulating environment for drivers with well-defined interfaces which isolated drivers from OS policies and from platform and I/O bus dependencies. In principle, this allowed driver development to be totally independent of OS development. In addition, the UDI architecture was intended to insulate drivers from platform specifics such as byte-ordering, DMA implications, multi-processing, interrupt implementations and I/O bus topologies.

I.e., UDI's "channel" architecture is the very opposite of "[relying] heavily on a micro-kernel design", it's the (rather successful) attempt of not relying on a specific kernel design.

FYI:

An UDI implementation may implement any channel event as a direct call to its target. The only thing the UDI environment does at those times is changing the owner of the control block and looking up the address of the called function.

Love4Boobies wrote:Hmm, this is where the problem comes from, you are misinterpreting the abstraction provided by channels. Do you only see one way to exchange control blocks? Your feedback will help me improve the Uniform Driver Interface article on the wiki.

The choice of "channel" seems to be quite misleading. After reading the NIC document again I realize that channels are more like IOCTL, which I really will NEVER implement.

Anyway, I think I understand the basics of the NIC interface now, except for in which context received packets are sent. Is it in the context of an ISR, or in the context of something else? And if it is not in the context of an ISR, how does this work? If it is in the context of ISRs, then buffer descriptors queues must be synchronized with spinlocks rather than semaphores.

Given that the code is written in portable C, does not rely on a flat memory model, I think it might be possible to supply the UDI interface for NICs to RDOS. Still, the overhead is much larger than I usually have in NIC-drivers, so I bet it would NOT outperform native drivers in RDOS.

Love4Boobies wrote:

rrdos wrote:Look at Intel's ACPICA as a very good example of how a complex interface should be implemented in an OS-independent manner. The document has no requiremens for IPC-functions, and clearly states the procedures that the OS needs to implement. The code is also highly portable and compiles with a 32-bit segmented memory model.

Reminds me of UDI

Hmm. Where is the list of OS required functions for a functional UDI environment?

rdos wrote:Hmm. Where is the list of OS required functions for a functional UDI environment?

Replace "required functions" with "required functionality", and you might start getting the idea what UDI is actually about. Your starting point, then, would be the UDI Environment Implementers Guide.

rdos wrote:

Love4Boobies wrote:Hmm, this is where the problem comes from, you are misinterpreting the abstraction provided by channels. Do you only see one way to exchange control blocks? Your feedback will help me improve the Uniform Driver Interface article on the wiki.

The choice of "channel" seems to be quite misleading. After reading the NIC document again I realize that channels are more like IOCTL, which I really will NEVER implement.

I think it would be a good time to stop making assumptions You are making interpretations about the UDI model based on an UDI metalanguage.

rdos wrote:Hmm. Where is the list of OS required functions for a functional UDI environment?

That's like asking where the list of OS functions for supporting C is. There's no such thing---unless you are actually trying to port one of the existing environments from the reference implementation (which, in my analogy, is similar to asking what is needed to port GCC in particular). You might, however, be interested in the UDI Environment Implementers Guide, although note that it was written against UDI 1.0. It will answer more of the questions I noticed you have.

rdos wrote:Given that the code is written in portable C, does not rely on a flat memory model, I think it might be possible to supply the UDI interface for NICs to RDOS. Still, the overhead is much larger than I usually have in NIC-drivers, so I bet it would NOT outperform native drivers in RDOS.

That's possible, of course, in the same sense that you can probably write better assembly than your compiler can. Hopefully, your interface increases scalability by avoiding locks as well. But here's the catch: you can implement UDI on top or in parallel with your existing driver interface.

OK, so if there is an AHCI or USB-disc driver for UDI, I'd be willing to put down some work in providing an UDI-environment for RDOS.

However, since it seems like the reference implementation is not static, rather is changing, I would not want to just extract the code with CVS/SVN, and make my own branch, but would want to post all patches / support for RDOS to the official reference implementation much the same way I do in the OpenWatcom project. However, my experience with patching GCC with RDOS support are not good. It took ages to get patches for trivial things accepted, and I don't want to have to put up with things like that. So is it possible to get write access to the repository for this task, or alternatively, is there a timely procedure for getting patches accepted?

As I already wrote before, I have a working ACPICA environment with only minor modifications to the code itself, that proves the concept of running C-code in the kernel. However, since the ACPICA project is rather static, I don't think I need to provide the patches to that project.

Well, here's where the bad news is: ever since 2004, udiref (the reference implementation) is a dead project (potentially resurrectable, though). There are a few open source UDI drivers in udiref and quite a few more that were implemented by either SCO or different hardware vendors (see SCO's FTP server). However, most of those drivers are not relevant to current hardware.

Hence, you have three options:

• To do exactly what you said and continue working on the reference implementation yourself---don't worry, it's documented for the most part. Don't worry about any changes, it's very unlikely that the original repository will see any changes anytime soon.
• To write your own UDI environment following the specifications. This is not as bad as it sounds; fortunately, UDI is far less complicated than ACPI.
• To not use UDI at all. But if you do implement it and write a few drivers, you might just attract some more people on this forum to use UDI and they might, in turn, write drivers that you can use for your project.

rdos wrote:So is it possible to get write access to the repository for this task, or alternatively, is there a timely procedure for getting patches accepted?

I think you completely misunderstood the purpose of the reference implementation. It is an example for how UDI could be implemented, not a framework to be ported to your OS. Your OS has quite specific requirements and conditions, so a "good" UDI implementation for RDOS might look significantly different from what udiref provides.

So, even if it were a "live" project, I very much doubt they'd be interested in adding "RDOS patches" to udiref, simply because it's beside the point.