Slashdot Mirror

Many years ago i was associated with Project UDI, the Uniform Driver Interface. The goal was to make a uniform ABI/API for device drivers. On Machines with the same hardware target (say, 32 bit x86) you would have binary compatibility. The same driver works on Solaris or Windows. For other platforms, they'd be at least source compatible. It worked in theory, and somewhat in practice - I think UnixWare shipped this as their native Device Driver Interface.

But you never heard of it. Part of it was the SCO/Caldera fiasco. 'Nuff said about that.

But part of it also was the fact that people had vested interests in this failing. Most famously, Stallman didn't like it. For now you could ship drivers without source for all i386 targets (not that having the normal Linux DDI prevented that before). But it was fun that I worked on something shipped in a commercial kernel, and also something that pissed off Stallman.

More importantly, the people who want this are necessarily in the weakest position. MS doesn't want this - everyone makes Windows drivers. They get nothing from it except lower exclusivity. (The fact that Gates and Stallman were on the same side of this should have given Stallman time to reflect). They'd never allow the UDI code to touch their kernel. One or two other big UNIX vendors feigned interest, but they had the same issue - they had exclusive (to UNIX) device drivers, and they'd lose exclusivity. Only Caldera used it. It was their project, and it helped their forked codebase - they had both UnixWare and OpenServer (very old) code bases they needed drivers for, and it made it an easier target for device makers.

None of the issues were tech issues, they all were people issues, which haven't gone away in the intervening years.

It sounds like he might want to look into Project UDI. It's a device driver abstraction that allows source and to some level binary compatible device drivers across platforms with the UDI environment. I did a little work in it, and from a very top level look at his kernel threading model, looks like a good fit with how UDI does things. It's not very well known, and being a Caldera/NewSCO type thing (developed initially way before the current management started the legal stuff) now has political baggage as well.

Actually, I was a part of this. UDI is The Uniform Driver Interface Project. I'm not sure what they mean about San Jose part, we're Midwest. Maybe another group did this in parallel? I don't know. Maybe they ported the USB stack in OSR5 is native DDI and built on USB. I can say that the UDI USB stack that shipped in OpenServer 8.0 is BSD code. Not that this is illegal, or violates any contracts. Just it's assholish of them to (threaten to) sue BSD when they use BSD code themselves. Wouldn't be the first time - ATT UNIX had many BSD enhancements, but that didn't stop them from suing.

The theory of UDI is you have this virtual environment thats consistent across all architectures. All drivers are 100% source compatible across all architectures. Environments with the same C ABI are binary compatible.

At one time, back when SCO/Caldera actually sold OSes for a living, they wanted to migrate people from OpenServer to UnixWare. One of the problems they saw was with device drivers. Nobody wanted to spend real money to port drivers to UnixWare. Why spend all that testing for an OS that won't give you a lot of sales (because lack of OS sales means no market)? So they came up with Project UDI, which is a driver environent, consistent across all platforms. You virtualize things and give a common API. The environment also handles synchronization, so you don't have to worry about locking data - you'll never get preempted. I forgot the timing, but I think UnixWare had this on top of the 7.x DDI, then OpenUnix 8 (which had a LOT of Linux stuff) had UDI as the native DDI, and the old DDI on top of it.

We talked to other major UNIX guys, but the proprietary ones said no; they were big enough in most cases for people to target their OS specifically, so it became strategic to not support having drivers for other OSes. Stallman hated (hates? it's pretty much dead) the idea because it makes it easier to close drivers (binary compatibility across a large number of potential platforms).

It was a weird environment, and you don't program like normal DDIs, it's more of a message passing architecture, with marshalling and unmarshalling of parameters on either side of a call (the marshalling was a major source of bugs early on). It seems pretty much dead in the water now. And yes, the USB stack is definitely the "Net"BSD one. I put "Net" in quotes because the stack is essentially shared across Net,Free,Open, and I assume now, DragonflyBSD.

This wrapper sounds a bit like the UDI Project creates a universally consistent driver DDI across all platforms. All drivers are source code compatible for all platforms with an environment. Drivers are binary compatible between platforms with a common C ABI.

Unfortunately Caldera was the main weight behind this, back when they actually did something silly like write code to make money instead of sue. They fell on hard times and essentially pulled support, and it's been dead in the water since.

I did some small work on Project UDI, the Uniform Driver Interface. It attempts to make a consistent DDI across all platforms. It aims to make device drivers source compatible across all platforms, and binary compatible across architectures with the same C ABI. Pretty slick, you don't need to worry about synchronization primitives, the environment handles all that for you, giving you ways of handling interupts, getting memory... etc.

Caldera was one of the big supporters actually, back in the "lets, Idunno, actually ENGINEER something that people would want to buy" instead of getting the lawyers involved. Never really went anywhere unfortunately. The big OSes don't need it because people already make drivers for them. The smaller ones tended to have philosophical differences (RMS hated it for Linux, made it easier for binary only drivers he thought). I'ts been pretty much dead since 2001, being in the odd place of having drivers but no OSes.

OpenUNIX 8 is basically UnixWare with Linux binary support and some new driver stuff in it - SCO has been a supporter of Project UDI since the beginning, and this is there new kernel Device Driver Interface.

The old SCO 5, SVR3 based, file system symlinked to an ounce of it's life code base is called OpenServer. Still being sold, though I bet it's had a fork stuck in it for quite some time.

I suppose it's reasonable to expect a company to produce drivers for Linux, but remember, there are umpteen billion operating systems out there, and these companies don't have the time or resources to develop for all of them.

That's why we should all be supporting Project UDI (Uniform Driver Interface). You write a hardware driver once and it works (unchanged) on all UDI-enabled operating systems. What could be better?

One thing I'm currently semi-involved with is writing some UDI drivers.

UDI is a driver environment that abstracts normal system services and makes them consistent across multiple operating systems. A conformant driver is source compatible across all systems and binary compatible across systems with the same ABI. Low penetration platforms (like Be and others) if they created the environment, could use something like this to boost their driver availability.

The environment itself is a bit strange at first, most functions are asynchronous and have callbacks, so you rely a lot more on state information. It's very modular, and the APIs to other modules are function vectors called metalanguages. But once your in your in a call in your module, it's serialized so you have no synchronization issues - the environment handles this. The modules can run anywhere, on multiple cpus, or even (in theory) on multiple machines in a cluster.

Damn typos! Try this link instead...

Hmm, perhaps Linux should cater more towards hardware vendors... Developing a standard by which binary drivers can be easily utilized.

Hmm. A standard for binary drivers? Um, you mean like Project UDI? Oh yes, I forgot -- RMS had a petulant rant about it, so I guess we can't support a worthwhile effort that is the best chance for marginalized OS's to move into the mainstream. Nevermind!

Not for MS Windows, but for all x86 unixes: http://www.project-udi.org/.
(See also commentary from LWN).

If we imagine a number of operating systems and hardware developers, all cooperating on an equal footing, UDI (if technically feasible) would be a very good idea. It would permit us to develop just one driver for any given hardware device, and then all share it. It would enable a higher level of cooperation.

• "People could run free GPL-covered Linux drivers with Windows systems." If the GPL-covered drivers are dynamically loaded, this is probably true. However, the cat's out of the bag on this one; the proprietary company could always port the GPL driver to UDI themselves.
• "It would not directly hurt us, either; but the developers of GPL-covered free drivers could be discouraged to see them used in this way, and that would be very bad." Look at the flip side; developers of GPL-covered free drivers might be very encouraged to see their driver used on a wide variety of free kernels, knowing that their efforts have been leveraged to increase the greater good. (This could outweigh the downside of possible use by proprietary systems, couldn't it?)
• "People could run non-free Windows drivers on GNU/Linux systems." The cat's out of the bag on this one already also; since Linus has declared the API between the Linux kernel and device drivers to be public, and not covered by the GPL, it is already possible to distribute proprietary drivers for Linux. (One might try to argue that this is still improper under the GPL, but Linus would have to enforce it, and it appears that he won't.)
• "To the extent that the community began to accept the temptation, we would be moving to using non-free drivers instead of writing free ones." This is a user/developer education issue more than anything. It is important to help people understand the value of freedom for its own sake. Many people have trouble with that concept (witness the struggles of the Libertarian Party), since too many people are willing to sacrifice liberty for convenience. This is an ongoing battle, with or without UDI.
• "But why encourage the community to be weaker than it needs to be? Why make unnecessary difficulties for the future of free software? Since UDI does no good for us, it is better to reject UDI." Having a lack of stable APIs for device drivers makes us weaker. (Look at how often Linux drivers have needed to be recoded to adapt to kernel architectural changes.) Having incompatible drivers between different free operating systems (e.g. Linux, FreeBSD, NetBSD, HURD) creates unnecessary difficulties, keeping us much more factionalized, which makes us much weaker than Windows. If free operating system developers could cooperate and leverage their efforts, we have a lot to be gained here. What does Microsoft have to gain here? Not much; the hardware vendors will always write drivers for Windows without Microsoft lifting a finger, as long as Windows is the dominant platform. If we could level the playing field with UDI, Microsoft would lose a key strategic advantage they currently enjoy over free operating systems.
• "Given these consequences, it is no surprise that Intel, a supporter of UDI, has started to ``look to the Linux community for help with UDI.'' How does a richand self-seeking company approach a cooperating community? By asking for a handout, of course. They have nothing to lose by asking, and we might becaught off guard and say yes." I agree that Intel was less than tactful in asking (nay, expecting) Linux developers to assume the burden of UDI driver development. (Bear in mind, however, that UDI originated with SCO a number of years before Intel recently jumped on the bandwagon; it started as a standardization attempt for UNIX systems.) Indeed, Intel is hoping to freeload off our efforts. They should have offered some fair compensation for our efforts, such as writing their own UDI drivers for all old and new Intel hardware, and releasing those drivers as free software along with hardware specifications. A commitment like that would have been taken more seriously. Instead, they asked for a handout, and it backfired on them. Now we have many honorable members of the free software community hostile to the idea of UDI (irrespective of the technology) because of the (correct) perception that Intel (and others) would like to take advantage of our efforts in this area. At the same time, "don't cut off your nose to spite your face." Free software can benefit greatly from a common API (whether UDI or not), and refusing to use one because it might help "the enemy" still leaves us in the same mess we've been in for too long. Let's evaluate it on the benefits we can derive, not on the benefits we can deny to the opposition.
• "One way to make a deal a good one could be by modifying the UDI project itself. Eric Raymond has proposed that UDI compliance could require that the driver be free software. That would be ideal, but other alternatives could also work. Just requiring source for the driver to be published, and not a trade secret, could do the job--because even if that driver is not free, it would at least tell us what we need to know to write a free driver." Actually, a good start would be to convince them to honor their commitment to place the specification in the public domain as described in the following paragraph from the "Project UDI Policies and Procedures" page:
  
  

  The definition of any specification developed by the working group will be placed in the public domain, not subject to copyright, patent or any other intellectual property right, so that any party may implement or utilize the specification. However, any party may develop and assert intellectual property rights over a particular implementation of the interface.

  This statement couldn't be any more clear, yet the UDI 1.0 specification as finally released has an entire page filled to the brim with copyright declarations. A good question for Project UDI is why they failed to follow through on this commitment. (The lawyers probably insisted...)
  
  UDI drivers released by vendors would be valuable to us, even if some of those vendors fail to release their UDI drivers as free software. First, the source to a non-free driver might be published by the vendor, simply to increase market share -- UDI compatibility is only guaranteed at the source level. Even if the source is not released, the UDI driver is tightly constrained; it must funnel all interaction with outside code and actual devices through the UDI environment implementation -- this allows "black box" investigations that can easily see what effects the driver has, even if the source is not available. This should make UDI drivers easier to reverse-engineer than Windows drivers, especially if a special "test-rig" UDI environment implementation was created to facilitate such reverse-engineering.
• "One difficulty with any deal with Intel about UDI is that we would do our part for Intel at the beginning, but Intel's payback would extend over a long time." Not necessarily; we could implement UDI environments for free operating systems and wait for them to start creating some UDI drivers before we put too much more effort into it. After all, they have a vested interested; they'll surely invest some effort into writing drivers if they can't get us to subsidize their bottom line with charity work. Free-software developers might still port some drivers in their own interest (e.g. a FreeBSD hacker porting a Linux driver to UDI, perhaps) but we wouldn't have to "loan" our efforts to Intel (et al) if we choose not to. Even if we don't, we might as well implement UDI environments to take advantage of the work of proprietary companies...

If we imagine a number of operating systems and hardware developers, all cooperating on an equal footing, UDI (if technically feasible) would be a very good idea. It would permit us to develop just one driver for any given hardware device, and then all share it. It would enable a higher level of cooperation.

• "People could run free GPL-covered Linux drivers with Windows systems." If the GPL-covered drivers are dynamically loaded, this is probably true. However, the cat's out of the bag on this one; the proprietary company could always port the GPL driver to UDI themselves.
• "It would not directly hurt us, either; but the developers of GPL-covered free drivers could be discouraged to see them used in this way, and that would be very bad." Look at the flip side; developers of GPL-covered free drivers might be very encouraged to see their driver used on a wide variety of free kernels, knowing that their efforts have been leveraged to increase the greater good. (This could outweigh the downside of possible use by proprietary systems, couldn't it?)
• "People could run non-free Windows drivers on GNU/Linux systems." The cat's out of the bag on this one already also; since Linus has declared the API between the Linux kernel and device drivers to be public, and not covered by the GPL, it is already possible to distribute proprietary drivers for Linux. (One might try to argue that this is still improper under the GPL, but Linus would have to enforce it, and it appears that he won't.)
• "To the extent that the community began to accept the temptation, we would be moving to using non-free drivers instead of writing free ones." This is a user/developer education issue more than anything. It is important to help people understand the value of freedom for its own sake. Many people have trouble with that concept (witness the struggles of the Libertarian Party), since too many people are willing to sacrifice liberty for convenience. This is an ongoing battle, with or without UDI.
• "But why encourage the community to be weaker than it needs to be? Why make unnecessary difficulties for the future of free software? Since UDI does no good for us, it is better to reject UDI." Having a lack of stable APIs for device drivers makes us weaker. (Look at how often Linux drivers have needed to be recoded to adapt to kernel architectural changes.) Having incompatible drivers between different free operating systems (e.g. Linux, FreeBSD, NetBSD, HURD) creates unnecessary difficulties, keeping us much more factionalized, which makes us much weaker than Windows. If free operating system developers could cooperate and leverage their efforts, we have a lot to be gained here. What does Microsoft have to gain here? Not much; the hardware vendors will always write drivers for Windows without Microsoft lifting a finger, as long as Windows is the dominant platform. If we could level the playing field with UDI, Microsoft would lose a key strategic advantage they currently enjoy over free operating systems.
• "Given these consequences, it is no surprise that Intel, a supporter of UDI, has started to ``look to the Linux community for help with UDI.'' How does a richand self-seeking company approach a cooperating community? By asking for a handout, of course. They have nothing to lose by asking, and we might becaught off guard and say yes." I agree that Intel was less than tactful in asking (nay, expecting) Linux developers to assume the burden of UDI driver development. (Bear in mind, however, that UDI originated with SCO a number of years before Intel recently jumped on the bandwagon; it started as a standardization attempt for UNIX systems.) Indeed, Intel is hoping to freeload off our efforts. They should have offered some fair compensation for our efforts, such as writing their own UDI drivers for all old and new Intel hardware, and releasing those drivers as free software along with hardware specifications. A commitment like that would have been taken more seriously. Instead, they asked for a handout, and it backfired on them. Now we have many honorable members of the free software community hostile to the idea of UDI (irrespective of the technology) because of the (correct) perception that Intel (and others) would like to take advantage of our efforts in this area. At the same time, "don't cut off your nose to spite your face." Free software can benefit greatly from a common API (whether UDI or not), and refusing to use one because it might help "the enemy" still leaves us in the same mess we've been in for too long. Let's evaluate it on the benefits we can derive, not on the benefits we can deny to the opposition.
• "One way to make a deal a good one could be by modifying the UDI project itself. Eric Raymond has proposed that UDI compliance could require that the driver be free software. That would be ideal, but other alternatives could also work. Just requiring source for the driver to be published, and not a trade secret, could do the job--because even if that driver is not free, it would at least tell us what we need to know to write a free driver." Actually, a good start would be to convince them to honor their commitment to place the specification in the public domain as described in the following paragraph from the "Project UDI Policies and Procedures" page:
  
  

  The definition of any specification developed by the working group will be placed in the public domain, not subject to copyright, patent or any other intellectual property right, so that any party may implement or utilize the specification. However, any party may develop and assert intellectual property rights over a particular implementation of the interface.

  This statement couldn't be any more clear, yet the UDI 1.0 specification as finally released has an entire page filled to the brim with copyright declarations. A good question for Project UDI is why they failed to follow through on this commitment. (The lawyers probably insisted...)
  
  UDI drivers released by vendors would be valuable to us, even if some of those vendors fail to release their UDI drivers as free software. First, the source to a non-free driver might be published by the vendor, simply to increase market share -- UDI compatibility is only guaranteed at the source level. Even if the source is not released, the UDI driver is tightly constrained; it must funnel all interaction with outside code and actual devices through the UDI environment implementation -- this allows "black box" investigations that can easily see what effects the driver has, even if the source is not available. This should make UDI drivers easier to reverse-engineer than Windows drivers, especially if a special "test-rig" UDI environment implementation was created to facilitate such reverse-engineering.
• "One difficulty with any deal with Intel about UDI is that we would do our part for Intel at the beginning, but Intel's payback would extend over a long time." Not necessarily; we could implement UDI environments for free operating systems and wait for them to start creating some UDI drivers before we put too much more effort into it. After all, they have a vested interested; they'll surely invest some effort into writing drivers if they can't get us to subsidize their bottom line with charity work. Free-software developers might still port some drivers in their own interest (e.g. a FreeBSD hacker porting a Linux driver to UDI, perhaps) but we wouldn't have to "loan" our efforts to Intel (et al) if we choose not to. Even if we don't, we might as well implement UDI environments to take advantage of the work of proprietary companies...

If we imagine a number of operating systems and hardware developers, all cooperating on an equal footing, UDI (if technically feasible) would be a very good idea. It would permit us to develop just one driver for any given hardware device, and then all share it. It would enable a higher level of cooperation.

• "People could run free GPL-covered Linux drivers with Windows systems." If the GPL-covered drivers are dynamically loaded, this is probably true. However, the cat's out of the bag on this one; the proprietary company could always port the GPL driver to UDI themselves.
• "It would not directly hurt us, either; but the developers of GPL-covered free drivers could be discouraged to see them used in this way, and that would be very bad." Look at the flip side; developers of GPL-covered free drivers might be very encouraged to see their driver used on a wide variety of free kernels, knowing that their efforts have been leveraged to increase the greater good. (This could outweigh the downside of possible use by proprietary systems, couldn't it?)
• "People could run non-free Windows drivers on GNU/Linux systems." The cat's out of the bag on this one already also; since Linus has declared the API between the Linux kernel and device drivers to be public, and not covered by the GPL, it is already possible to distribute proprietary drivers for Linux. (One might try to argue that this is still improper under the GPL, but Linus would have to enforce it, and it appears that he won't.)
• "To the extent that the community began to accept the temptation, we would be moving to using non-free drivers instead of writing free ones." This is a user/developer education issue more than anything. It is important to help people understand the value of freedom for its own sake. Many people have trouble with that concept (witness the struggles of the Libertarian Party), since too many people are willing to sacrifice liberty for convenience. This is an ongoing battle, with or without UDI.
• "But why encourage the community to be weaker than it needs to be? Why make unnecessary difficulties for the future of free software? Since UDI does no good for us, it is better to reject UDI." Having a lack of stable APIs for device drivers makes us weaker. (Look at how often Linux drivers have needed to be recoded to adapt to kernel architectural changes.) Having incompatible drivers between different free operating systems (e.g. Linux, FreeBSD, NetBSD, HURD) creates unnecessary difficulties, keeping us much more factionalized, which makes us much weaker than Windows. If free operating system developers could cooperate and leverage their efforts, we have a lot to be gained here. What does Microsoft have to gain here? Not much; the hardware vendors will always write drivers for Windows without Microsoft lifting a finger, as long as Windows is the dominant platform. If we could level the playing field with UDI, Microsoft would lose a key strategic advantage they currently enjoy over free operating systems.
• "Given these consequences, it is no surprise that Intel, a supporter of UDI, has started to ``look to the Linux community for help with UDI.'' How does a richand self-seeking company approach a cooperating community? By asking for a handout, of course. They have nothing to lose by asking, and we might becaught off guard and say yes." I agree that Intel was less than tactful in asking (nay, expecting) Linux developers to assume the burden of UDI driver development. (Bear in mind, however, that UDI originated with SCO a number of years before Intel recently jumped on the bandwagon; it started as a standardization attempt for UNIX systems.) Indeed, Intel is hoping to freeload off our efforts. They should have offered some fair compensation for our efforts, such as writing their own UDI drivers for all old and new Intel hardware, and releasing those drivers as free software along with hardware specifications. A commitment like that would have been taken more seriously. Instead, they asked for a handout, and it backfired on them. Now we have many honorable members of the free software community hostile to the idea of UDI (irrespective of the technology) because of the (correct) perception that Intel (and others) would like to take advantage of our efforts in this area. At the same time, "don't cut off your nose to spite your face." Free software can benefit greatly from a common API (whether UDI or not), and refusing to use one because it might help "the enemy" still leaves us in the same mess we've been in for too long. Let's evaluate it on the benefits we can derive, not on the benefits we can deny to the opposition.
• "One way to make a deal a good one could be by modifying the UDI project itself. Eric Raymond has proposed that UDI compliance could require that the driver be free software. That would be ideal, but other alternatives could also work. Just requiring source for the driver to be published, and not a trade secret, could do the job--because even if that driver is not free, it would at least tell us what we need to know to write a free driver." Actually, a good start would be to convince them to honor their commitment to place the specification in the public domain as described in the following paragraph from the "Project UDI Policies and Procedures" page:
  
  

  The definition of any specification developed by the working group will be placed in the public domain, not subject to copyright, patent or any other intellectual property right, so that any party may implement or utilize the specification. However, any party may develop and assert intellectual property rights over a particular implementation of the interface.

  This statement couldn't be any more clear, yet the UDI 1.0 specification as finally released has an entire page filled to the brim with copyright declarations. A good question for Project UDI is why they failed to follow through on this commitment. (The lawyers probably insisted...)
  
  UDI drivers released by vendors would be valuable to us, even if some of those vendors fail to release their UDI drivers as free software. First, the source to a non-free driver might be published by the vendor, simply to increase market share -- UDI compatibility is only guaranteed at the source level. Even if the source is not released, the UDI driver is tightly constrained; it must funnel all interaction with outside code and actual devices through the UDI environment implementation -- this allows "black box" investigations that can easily see what effects the driver has, even if the source is not available. This should make UDI drivers easier to reverse-engineer than Windows drivers, especially if a special "test-rig" UDI environment implementation was created to facilitate such reverse-engineering.
• "One difficulty with any deal with Intel about UDI is that we would do our part for Intel at the beginning, but Intel's payback would extend over a long time." Not necessarily; we could implement UDI environments for free operating systems and wait for them to start creating some UDI drivers before we put too much more effort into it. After all, they have a vested interested; they'll surely invest some effort into writing drivers if they can't get us to subsidize their bottom line with charity work. Free-software developers might still port some drivers in their own interest (e.g. a FreeBSD hacker porting a Linux driver to UDI, perhaps) but we wouldn't have to "loan" our efforts to Intel (et al) if we choose not to. Even if we don't, we might as well implement UDI environments to take advantage of the work of proprietary companies...

See my previous post for a long response to another poster. I'll only address new points below...

This, I believe, may be only a chimera; there are enough differences between the mechanisms that are used to protect driver and kernel data structures from interrupt service routines and peer-processor access in the various OSs that it may not even be possible to create a set of UDI drivers, much less port them across major kernel architecture change.

Most such policy decisions (uniprocessor vs. multiprocessor, singletasking vs. multitasking, privileged vs. userspace, synchronous vs. asychronous I/O, VM or not, protected memory or not, etc.) are entirely contained within the UDI environment implementation on the OS side, and unknown to the UDI driver itself. In fact, the UDI driver code can be simpler, because it doesn't deal with interrupt masks, task switching, synchronization, etc. (Since the environment has to deal with these issues, the environment implementation is probably harder, but it only has to be done once for all drivers on that OS.)

Since some devices MUST BE present in the kernel to access a boot device (and console), there is no way to prevent rebuilding drivers into a kernel. The current system of modular drivers already permits non-boot drivers to be excluded from the kernel image, and these modules can be distributed as separate packages. BTW, I just ran a line count on 2.2.5; there is a total of 1005095 lines of source code.

While it makes the most sense for UDI drivers to normally be loaded dynamically, there's no reason some bootstrap drivers couldn't be statically linked with the kernel. After booting, those drivers could continue to operate, or possibly be replaced with dynamically-loaded (possibly newer) versions.

In my Linux 2.2.12 tree (generic Red Hat 6.1, I think), "wc -l `find . -name '*.[ch]' -print`" gives me 1642672 lines. Most of this is device drivers: 1117142 lines, or 68% of the total. Surely the kernel would be more manageable if this mass of code wasn't so tightly coupled with kernel internals?

The performance will be that bad, so the existing sort-of APIs will be used and all that will have happened is a lot of unused work creating the code to implement and support the APIs.

I agree that the jury is still out, when it comes to UDI performance. They've made efforts to keep it high-performance, but it's unproven. Even if the performance is poor, there are good reasons to support UDI.

If the Linux, bsd, etc. communities had been the driving aganecy for UDI, there's a good chance that the result would be a benefit to both users and device manufacturers. Since the current initiative is by M$ and the vendors that want to dump their M$-Windows drivers on Linux, bsd, etc., then YES it would be a REALLY, REALLY bad thing to implement UDI in Linux.

Why aren't the Linux/BSD communities driving UDI? UDI can be good for everyone but Microsoft. Project UDI is not a Microsoft initiative; they're not even a participant! (They also have the most to lose, as the most entrenched OS vendor.) The history goes back years (1993, maybe?) to a multivendor effort to create common drivers for UNIX systems. Major participants include Sun, HP, SCO, Intel, Compaq, IBM and others. SCO and IBM are putting UDI support in AIX, Unixware and Monterey. (For Monterey, I'm told it will be the only API for device drivers.)

Project UDI has an (outdated) HTML presentation that has some overview information to help give you a broad sense of the architecture -- it's well worth reading.

Project UDI (Uniform Driver Interface) is approaching this write-once, run-anywhere driver implementation idea in a fairly comprehensive manner.

While it's not ready yet, the architecture is impressively clean and powerful. The same UDI driver code could potentially run (with only a recompile, no code changes) on a Windows system (e.g. Win95 or NT), a Unix system (e.g. Solaris or Linux), a small multitasking system without VM (e.g. Amiga), a small singletasking system (e.g. MS-DOS), or an intelligent I/O processor (e.g. I2O)... Each of these systems would need appropriate implementations of the UDI environment, but could run the same drivers. UDI drivers are written with very few assumptions about multitasking, memory protection, etc. You could even protect the OS from buggy drivers! (At a performance cost.)

As a case in point, SCO's next-generation Monterey operating system is slated to use UDI as its sole driver API...

• Consider that with roughly 25% of the transistor count of a Pentium III, their Code Morphing software is able to give them roughly the performance of a 500-MHz Pentium III with a 700-MHz Crusoe chip. This chip executes VLIW "molecules", currently composed of up to 4 "atoms"; it has 4 functional units in the chip, and can do 4 operations per clock cycle.
  
• Now consider what they could do with 100% of the transistor count of a Pentium III. Perhaps 16 functional units executing in parallel, with the effective performance of a 2-GHz Pentium III from a 700-MHz chip? (It may not have the low-power benefits anymore, but it would attract all the power users searching for the fastest chip.)
  
• Even if the gains aren't quite so linear, it seems clear that more parallelism is possible, which could easily lead to speed jumps that Intel might not be able to match, given the extra complexity inherent in out-of-order execution on a superscalar chip like the Pentium III. (And would it really be a problem if that extra parallelism required 1024-bit VLIW instruction words?)
  
• Worse for Intel is the potential for Transmeta to adapt the Code Morphing system to work across multiple Crusoe CPU chips for a single x86 instruction stream. This could lead to an enormous performance increase, possibly at a fairly low cost as well, throwing an amount of silicon at the processing that wouldn't otherwise be manageable on a single die with current fabrication processes.
  
• Crusoe chips could be made to emulate multiple CPUs instead of a single one. This could be used to simulate an SMP arrangement, either on a single Crusoe CPU for testing, or on many Crusoe CPUs to combat the diminishing returns from trying to spread a single x86 stream across too many chips.
  
• An idealized "native" instruction set (let's call it the "Crusoe instruction set") should be created for Crusoe. This should be a CISC instruction set, not RISC or VLIW. It should be a clean architecture, more like M68K than x86. Many registers should be available (256? 1024?), and opcodes should exist to support compilers and hand-coded assembly (such as low-level OS or BIOS code). There should also be opcodes and flags to access special hardware features of the Crusoe chip. It should be possible to map almost any RISC or CISC instruction (or flag) directly into the Crusoe instruction set. Like the PowerPC, it should be able to handle big-endian and little-endian data with equal ease.
  
• The Crusoe instruction set could be used for new Crusoe-specific applications, without restricting future architectural changes in the underlying VLIW instruction set or the Code Morphing software itself.
  
• Higher-level translation software (implemented in the Crusoe instruction set) could then directly translate almost any instruction set into the Crusoe instruction set, which the Code Morphing software would then execute as efficiently as possible on the actual hardware in use. This would allow Crusoe to emulate many different CPUs without requiring a rewrite per emulated CPU for each architectural change to the VLIW instruction set or the Code Morphing software.
  
• Perhaps x86 instructions could be translated to the Crusoe instruction set, but that might be slower. For the x86 market, every ounce of speed still matters, so this may not be worthwhile.
  
• A host OS could be written in the Crusoe instruction set, which would create full Virtual Machine (VM) environments, possibly with diverse requirements. (Project UDI might be helpful here.) Just imagine one Crusoe CPU (or a group; only the Code Morphing software would necessarily know) running virtual machines simultaneously for all of the following: Mac (68K), Mac (PowerPC), Windows NT (x86), Windows 95 (x86), Linux (x86) and Solaris (SPARC). (Of course, the host OS would want to create a Crusoe-instruction-set virtual CPU per virtual machine...)
  
• Given a GCC backend to generate output in the Crusoe instruction set, a "native" Linux build would be trivial. (This might be more efficient than x86 Linux, although with a loss in binary compatibility.)

ok, RMS doesn't like it for pushing binary-only drivers. so this is not a good thing for "free software", but just for the linux-community. microsoft is not going to like UDI, because one of the main advantages of windows is, that it has drivers for everything. well, anyway i guess microsoft isn't affraid as much of linux than of the unification of the unix-market in progress, around open source and linux. unix can only win against windows when 10 different unix-vendoers stop reinventing the wheel 10 times. and this is happening with apache, samba, xfree86 and somehow also linux.
solaris x86, freebsd, SCOs openserver and unixware (and soon AIX ) are all able to run linux binaries. so users can stick with their unix-of-choice and still run the bulk of linux-software. but guess for which plattform developers are going to publish their software first... and this is going to have long-term impact.

ups, well, as i'm OT anyway, doesn anybody know why IBM did port linux to S/390 and not AIX ?