While we welcome (and encourage) the idea, we would like to get real-world exposure of hardware, driver, and OS combinations that we haven't yet tested before tackling that. Right now, we're comfortable being the "stewards" of the code and will gladly serve as the active maintainers of it. Folks wishing to include the source in an OS or other distribution are free to do so in accordance with our licensing terms.
The UDI Reference Implementation is a little different than most open source projects because it contains a body of kernel code that interacts with a large and formal specification. A large percentage of the code is common across OSes. It's easier to foster cooperation and sharing when that code is mastered in a "neutral" location.
There is precedent for distribution of kernel subsystems as external packages in at least the Linux case. The PCMCIA code was externally mastered for several years before it was rolled in. Yet most every Linux distribution has included it for several years because it provided value that many people wanted. Once everyone agreed it had enough exposure, it was folded into the core kernel.
If the BSD vs. GPL thing becomes a sticking point, we, the copyright
holders can fix that.
Performance is pretty good in the reference implementation. It is often better than legacy drivers in some aspects and worse in some others. We know of ways it can be made even better. Most of our focus so far has been on providing a portable and conformant reference implementation to enable mature drivers with adequate performance and simpler ports to other architectures and operating systems. Now that we have a widening pool of available environments and drivers, we've been able to measure real world performance and we're generally on par with legacy drivers. With a stable base, we've also only recently begun to really take advantage of the parallelism and scalability offered by the UDI architecture. We believe we can now address any remaining performance issues with no driver-visible changes.
UDI is a specification that builds on other specifications. For example, it mandates the use of freestanding ISO C. Such compilers (and programmers) are plentiful. A UDI driver doesn't exist as bytecode or within a virtual machine. The use of well-specified APIs and ABIs allows native opcodes to be used naturally. As an example, for IA32 the specified binary format is the SVR4 ABI. The use of ELF in kernel modules is quite natural to Linux, Solaris, and UnixWare. The outside "fringe" (like the MODULE entry points for LInux, the .dlkm sections for UnixWare, etc.) are easily handled by udisetup on the way onto the destination system. Because ELF is so well documented, it's easy to convert to other formats during installation, such as the COFF requirement for OpenServer kernel modules. So it really does work to build a binary (and source is even easier) on any of those systems and run it on the others.
No. They were picked to because they are available for hardware with
publicly documented interfaces and because they have been reviewed for
UDI "purity", making them well-suited to be sample drivers. Additional
drivers have been written for UDI and exercised in several of the existing
environments. Many of these drivers have been or will be published, and
can be found at the
UDI Products page.
We also expected developer resistance to requiring patched or custom kernels before using the environment. As such, we worked hard to provide an environment that worked on stock kernels of our target OSes and were willing to make some tradeoffs.
File last modified: 00:00 Thu January 1, 1970