1. Why has this code taken so long to become really open?
   
   Since Project UDI was founded, it has been the intent to provide a reference implementation under a freely available license. Many of the contributors worked for large companies with intellectual property concerns, so the initial work proceeded under an NDA under the requests of our legal staffs. This allowed the particpants to freely discuss details of hardware, OSes, and business plans (often with "competitors") while working on the project. We've always found a way for interested parties to have access to the source, but we're as glad as you are to be free of the NDA requirement and deliver this as an Open Source project.
   
   
2. Isn't UDI a conspiracy by hardware vendors for closed source drivers?
   
   UDI makes both source and binary driver distributions practical in much the same way as, say, the RedHat Package Manager (RPM) makes distributions of other software practical. Like RPM, UDI frees you from having to worry about the details of the target installation environment (Was the driver built for SMP or UP? Support for BIGMEM or not? Symbol versioning or not? The list goes on.) and lets you focus on writing drivers.
   
   
3. Why isn't this code in the master source tree of my favorite free OS?

   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.

4. Why a BSD license and not GPL?
   
   The UDI environment is coupled rather tightly to the OS kernel. Because it may need to use some undocumented OS interfaces, the UDI environment could reasonably be considered a derived work of the kernel and vice versa. We chose the BSD license to allow free distribution while avoiding the controversy of "derived works" in GPL. We do intend for the reference implementation to be an active free software project.

   If the BSD vs. GPL thing becomes a sticking point, we, the copyright holders can fix that.
   



5. What's performance like? Doesn't "portable" equate to "lowest common denominator" and therefore "slow"?

   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.

6. "Write once, run everywhere" is a familiar promise. How does this avoid the problems of Java?

   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.

7. Are these all the UDI drivers that exist?

   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 Project UDI Products page.
   
   

8. Since the UDI environment is currently mostly in a "layered" onto existing OS facilities, doesn't that hurt performance?
   
   Not really. There are certainly facilities that could benefit from tighter integration into the host OS but we didn't do so in the name of risk management during the prototyping phase. Because we were often developing the specification, the drivers, and the environment simultaneously, we tried to avoid debugging the host OS at the same time. There were some tradeoffs involved, but now that we've reached stability and reasonable performance, a tighter integration is practical to consider.

   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.

9. If the environment uses native interfaces behind the scenes, how can it be faster than native interfaces?
   
   As one example, we allow instance independence which isn't common in many existing driver models. By placing locks only around the entry points into a region (thus making them deterministic and analyzable for correctness) multiple driver instances can run in parallel on multiple processors without the OS or driver knowing this is happening.
   
   
10. Is this all the code that was developed by the UDI Prototyping Group while under NDA?
    
    No. There was more code written, but for various reasons not released at the same time as the initial drop. The reasons differ from module to module, but they range from the above concerns about "purity" to code that isn't complete enough to be useful or code that just never cleared the legal hurdles. Some of that code can be made readily available to interested parties, but is too distracting for a general purpose reference implementation. Feel free to ask if you're looking for specific pieces.

File last modified: 00:00 Thu January 1, 1970