UDI spec 0.90 available for review

The Uniform Driver Interface spec is available for public review until May 31. UDI is an initiative proposed by Intel and proprietary Unix vendors to create a single driver API. This would allow UDI drivers to run on any hardware platform and UDI-supporting OS without changing their source-code.

Comments

We already have a quite nice UDI, thankyou.

[Millennium]

It's called the Linux kernel's driver interface. It's clean and is very well documented. It has much example code available. O'Reilly has two well-written books on the topic.

Very true.

This UDI thing would also encourage distribution of binary driver images, which is a Bad Thing.

Have the ports of Linux to other platforms encouraged binary distributions? I don't think it has, and Linux does the same thing as UDI, just for programs (use it on many platforms without a recompile). Therefore, why would a port of UDI to Linux do this?

It's also probably an attempt by SCO to get a free ride by making future Linux drivers work with SCO (which would, BTW, be in grievous violation of the GPL).

RMS has taught you paranoia well. Yes, perhaps SCO would then be able to use Linux drivers. Remember, however, it goes both ways. Linux will suddenly be able to use drivers from these other Unices. Is this a Bad Thing? I can't see why it would be.

The current Linux driver model is working just fine. SCO and IBM can distill fun little PDF files if they like, but I'll keep on using the Linux kernel that I know works and has good device support today.

Certainly, that's your prerogative. But what if the Linux kernel had even better device support? Look at it this way: propple use different unices in different areas. But what if a developer could develop a single driver which could run on all Unices, and Linux to boot? That's going to be much more tempting than writing two drivers, one for Linux and one for everyone else.

Dilution of the GPL.

[jerodd]

If this means that vendors can distribute binary-only modules for Linux driver compatibility. doesn't that indicate a subtle dilution of the GPL? Firstly, no distribution can ship with these drivers linked in (in either /lib/modules or /initrd or implicitly). That is very bad. It also means that I can't send someone my Linux setup (kernel+modules) if I'm using any of these binary-only modules.

This also harms the GPL. I wish Linus hadn't made that statement about binary-only modules being allowed, because it wasn't his statement to make. Binary-only anything in the Linux kernel is a grievous curse that must be avoided at all costs. Let us not sacrifice the freedom of Linux in the future on the altar of some extra device support today.

We already have a quite nice UDI, thankyou.

[jerodd]

It's called the Linux kernel's driver interface. It's clean and is very well documented. It has much example code available. O'Reilly has two well-written books on the topic.

This is just another attempt of SCO, which is rapidly become the obsolete PC UNIX vendor, to make themselves important once more. It's also probably an attempt by SCO to get a free ride by making future Linux drivers work with SCO (which would, BTW, be in grievous violation of the GPL). This UDI thing would also encourage distribution of binary driver images, which is a Bad Thing.

The current Linux driver model is working just fine. SCO and IBM can distill fun little PDF files if they like, but I'll keep on using the Linux kernel that I know works and has good device support today.

We already have a quite nice UDI, thankyou.

[jerodd]

Because vendors will ship binary drivers for kernel 2.2.5 that sort of work. They work good enough for the vendor to stick penguin sticker on the side of the box. By the time kernel 2.4 comes along, the driver is terribly broken because it turns out the vendor made it full of ugly hacks that don't work with any other newer hardware, but they refuse to support the newer kernels. I've been through this more than once on OS/2. It is simply no fun.

Binary-only modules also violate the GPL, plain and simple. We can't tolerate that, or we might as well just rerelease Linux under the X11 licence.

The strength of the Linux kernel, which includes its device support, is its freed, opensource nature. Binary-only modules hurt that.

I should also add that support for SCO is our bottom zero priority. If anything, SCO should work to make Linux drivers usable in SCO (although that still violates the GPL), but not the other way around. SCO is effectively asking Linux developers right now to give them something for free.

Plusses and Minuses evident

[CodeShark]

(Hopefully this will not be a double entry; I attempted to submit it before and something kinda weird happened. If it is, moderators please push one of the two messages down)I've perused the website and introductory information and have copied the PDF's for perusal later. At first glimpse this appears to have some positive aspects, however, the vendors list was light on things like scanner manufacturers (other than HP), video card manufacturers, etc.

A potential positive from their site: "While Project UDI does not intend to "take a side" in the debate, we are taking steps to facilitate UDI deployment in the OpenSource Community... We will also be releasing reference implementations of the UDI environment for Linux and other operating systems, as well as sample drivers. These will all be open source distributions."

Side Notes:

• they linked to the ESR OpenSource definition page, not FSF. See the comments about binary drivers, etc. as to a possible reason why.
• They also have done a proof of concept with an Adaptec SCSI controller and an Interphase component which I did not immediately recognize.
• One of the systems was a Linux system compiled by Intel [Intel Linux, anyone? :^) ]

Because they did not mention the Linux Kernel Driver Interface, and binary drivers (which break the GPL) are allowed, this is not 100% a good thing, as Jerodd has previously noted. However, if the UDI is or could be made compliant with the Linux Kernel Driver interface, then this could potentially offer the community a larger installable bases of new "power" peripherals, etc. without always requiring us to reverse engineer the WinDoze drivers.