Slashdot Mirror
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.
Its more of an interface to the kernel/OS than an interface in the traditional way of thinking about interfaces (as an API, for example).
/dev all represent vastly different devices, but yet they can be written to/from with fread()/fwrite() etc. because they appear as standard UNIX file streams.
...
The driver can still do whatever it wants to at the low-level, its just that in order to function it has to provide fundamental exports that can be used by the kernel of the OS to get data in and data out.
Sort of in the same way that entries in
(I'm generalizing here)
IMHO, having a UDI spec published is a good thing as it means that more and more device drivers can be made available across the Unix sphere. Yes, there are disadvantages - there *may* (not necessarily *definite*) be less and less opportunity for hackers to release OpenSource drivers based on study of released specs from hardware manufacturers.
On the other hand it does mean that specialized hardware manufacturers who consider their device driver the 'first line of defense' against reverse engineering will be more prone to releasing drivers for Linux, BSD, and other UDI supporting OS'es.
Essentially, militant OSS dogma aside, this means more device drivers, which means more use of these OS'es in area's that would be relegated to having to bolt NT into an application area just because it has device drivers for the card.
I'm all for the UDI, I think its a positive thing. As a developer of Win9x/NT and Linux device drivers myself, I'm all for a more organized and standardized device driver industry, and if the UDI presents a degree of solidification in that area, then so be it.
My fundamental feeling about device driver development is that it's a good thing for those that enjoy it, and they'll always be able to continue this sphere, but for Linux and other such OS'es, its really time for its developers to move on from the lower-level stuff into the Applications arena, taking advantage of standardized efforts at the lower level to make super-cool Application development possible.
If there were, for example, a completely standardized and well implemented audio driver core for Linux, I could move on and write the killer multi-track recording system I want to run under Linux, instead of having to worry about whether or not I have read/write capabilities to sound hardware at the driver level.
Realistically, the only thing stopping me from launching on such a project is that the technology behind device drivers for audio devices under Linux is bogus - and if UDI means more device driver development occurring (OSS or non-OSS, I don't care as long as it works) this increases the chances that better audio drivers will be written by those that have an interest in writing them (those that profit from the hardware sales).
And this means that I can then move on to building a 'tractor' application for Linux that people will want to use without having to worry about how to get bytes flung around the bus
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
The uniformity is across operating systems, not across peices of hardware. So a single driver _source_ (note: UDI is source-level compatible, not binary!) can support Linux, *BSD, SCO, Solaris, Digital Unix, and others (I forget who all is signed up).
I think the UDI will actually make open-source drivers _more_ common. It's a source-level spec, so you'd have to recompile the driver for different operating systems. Most of the companies writting device drivers are hardware companies- device drivers are loss leaders to sell hardware. The biggest problem with support "alternative" (i.e. non-Windows) operating systems is the engineering effort required. With UDI, they can write (and release open-source, or at least source-available) one driver and get sales to numerous different operating systems.
At the Intel Developer's Forum, Intel announced
that they would be working on a Linux UDI implementation. Intel seems to be very supportive
of UDI.
Make sure to GPL your UDI device drivers, so that they don't show up on closed-source platforms.
Bruce
Bruce Perens.
I imagine that the spec has changed somewhat, though, so perhaps some of the restrictions have changed (like vendors being able to provide binary only drivers)
enjoy.
Currently, the only license information I can find distributed with the kernel itself is the GPL, in /usr/src/linux/COPYING. However, there seems to be the exception, spoken by Linus himself, that binary kernel modules are allowed as long as they don't require interface changes in the kernel proper. We've already had one such case - /dev/3dfx
If this is to be the case, we had better get it in writing and get it in writing ASAP - I can just picture the chaos when binary-only drivers start becoming common, and some kernel developer says "No, I contributed to the linux kernel under the GPL. Stop allowing binary modules, or take my 50K lines of code out of the kernel."
Not his statement to make? Sorry, but the last time I check, Linus was the final say of what did and did not make it into the Kernel. He may not own the GPL, but he does, for all intents and purposes, own the Linux kernel. Binary drivers are not against the GPL of the kernel, they just can't be distributed _as_ the kernel.
This space for rent. Call 1-800-STEAK4U
Linus and Co. weren't too thrilled about UDI. Mostly because hardware vendors would go back to making binary only drivers, and potential performance/stability issues.
"What do you mean you want programming specs? We got you a driver..", or "..driver acting really slow? Oh, we don't support UDI drivers on Linux". In some ways, it could be worse than nothing.
Personally, I think it would probably be good for the near term. But it would be bad precedent.
Actually, when Windows 95 was in beta, many hardware companies were balking at releasing Win95 drivers, preferring to use the DOS or Win3.1 interfaces in 95, which would have lead to Win95 having many of the same problems Win3.1 did as well as breaking plug and play.
Microsoft ended up writing a bucket load of drivers themselves for 95 - for example all of the Adaptec SCSI drivers are from MS. MS also wrote a Novell NetWare client because Novell initially wouldn't.
This is a similar situation to where Linux is now - most of the drivers are written "in house". However as adoption increases, it's hardly fair to have the kernel group keep up with the thousands of new devices coming out for the PC every minute. Commercial driver support is going to happen, and a spec like UDI could make it happen if only because it eliminates duplicative effort.
--
Business. Numbers. Money. People. Computer World.
Who said Microsoft would support UDI? They've got their own driver model.
Besides, what hardware released in the last 3 years doesn't have NT support? It's hardly a problem for them.
--
Business. Numbers. Money. People. Computer World.
Well, considering that UDI is only for new hardware, and Intel and Microsoft are going to kill the ISA slot next year, I doubt the ISA issues are that important.
How would UDI remove the existing parallel port drivers in Linux? (Parallel port as a system interface is also going a way real fast.)
--
Business. Numbers. Money. People. Computer World.
I've noticed that my postings have very high scores. While I do appreciated my own viewpoints, I think leaving it at 3 is enough; moderators SHOULD NOT score up my articles just because they like what they said. Many others have raised important points too and their articles are at 1. Score them instead.
Cheers,
Joshua.
--jon. Postel is dead. May we all mourn his, and our, loss.
Please explain how binary-only modules which I use, violate the GPL; I admit it is probably due to some mistake of mine, but as far as I recall, if someone sticks a binary-only module in a GPL'd system then they are not breaking any of the GPL's rules. Again, please correct me if I'm wrong.
In any case, I think that direct support from vendors is definitely a Good Thing; your OS/2 experiences are irrelevant in the Linux context - want to drag Amiga into this as well? Adoption of Linux by hardware vendors will boom in the next year, and I believe the UDI initiative might just be one of the catalysts.
You can be assured that most users would very much like to have their hardware supported in Linux/UnixWare/Solaris/whatbloodyever platform by the vendor; free/GPL'd drivers are definitely not going away, so you'll probably have these as well. The problem is with hardware for which OpenSource drivers do not exist, or are flaky; some sites are running with reasonably cutting-edge hardware, for which drivers are lacking. UDI might give support for such systems a boost.
In any case, this is a move towards defragmentation of Unixland; sure SCO, Sun, HP and others will get something free out of this, but it means greater unification in the face of the Redmond bastards. If you're afraid that Linuxland will "lose" in some way due to such initiatives, I think you need to take a look at your faith in this platform; once commercial interests have become involved in Linux (and I'm not talking about RedHat), you should expect market pressures and powerplay to figure in the platform's future - and that means stuff like UDI "muddying the waters" for you. Linux is being used in complete voilation of the GPL all the time - I know of at least three embedded systems which use a modified version of the Linux kernel - and you'll probably never know. Sure, this is not the same, but I just gave this as an example that once money comes into it, the rules change, license or no license.
In the near term, UDI might be appear to be a GoodThing (tm), mainly because there is the potential for more hardware support for vendors. However, UDI on Linux has two major flaws that can damage the entire community in the long term. BTW, this is based on the assumption that non-free closed-source drivers will proliferate under UDI.
The first is that UDI dictates how the driver architecture will work and behave. Kernel developers will lose the freedom to experiment with hardware interfaces to tweek the performance. Regardless of a common heritage, all UNIX-like systems are not created equal. A monolithic kernel behaves different from a micro kernel, and both can be tweeked differently. Just because a driver is a good design under one UNIX-like OS does not mean that it will be a good design under another UNIX-like OS.
Second, anything that promotes closed-source drivers in the Linux kernel (or *BSD kernel) is bad for the entire Linux movement. Device drivers are the most common source of instability in a OS kernel. If closed-source drivers become common, we will definitely begin to see articles in major magazines which complain about the instability of Linux, when really badly written 3rd party drivers are to blame. This will kill the reputation that Linux has developed for unmatched stability. (Don't believe me? Driver instability is the main reason why Windows 95 and NT is an unstable pig)
UDI helps other UNIX vendors much more than it helps the free software community. Let's avoid the temptation of the 'quick fix' if it involves giving up our main strength; our free-software roots.
I didn't mean the Parallel Port was going away (although its "optional" in the PC 99 spec). Only that ParPort scanners, video capture stuff, hard drives, and so on have already been pretty much replaced by USB, which is fine because the ParPort has always seemed kinda flaky as a perhiphreal interface.
--
Business. Numbers. Money. People. Computer World.
The current Linux driver model is working just fine.
Yes, unless you have a box which Linux doesn't support, or doesn't support well. Or you are trying to run evil closed OSs like Solaris x86 or SCO. As far as a production system goes, the Linux decision might come down to whether a driver is available or not.
And don't forget all major commerical unixes will run on IA64, along with Linux. UDI support will be pretty much mandatory for any hardware vendor. Yet you are proposing looking this gift horse in the mouth to wait for someone to write a Linux native in their spare time.
My understanding is that non-GPL drivers are specifically allowed by the Linux licence, probably to encourage commercial support. And the native Linux interface is not going away, if there are are performance problems or you are worried about freedom issues.
--
Business. Numbers. Money. People. Computer World.
For those of us who run machines for profit-making corporations there's also the Best Possible Server Good Thing (tm). A different sort of ideology.
--
Business. Numbers. Money. People. Computer World.
OK, I stand corrected. Although, it does say Copyright Microsoft all over it, with no Adaptech copyright.
--
Business. Numbers. Money. People. Computer World.
Okay, now I know that this post will be followed with "But my x doesnt work!" And obviously we have a little ways to go, but I didn't think that drivers were really a problem for Linux.
My Intel ActionMedia II Display Adapter/A (speaking of Intel) isn't supported. I want video4linux for it NOW!
Admittidly, I'd like to see usb support (Inaky?) now, but it seems to me that Linux has superior device support right now. I mean, Linux supports things that NT doesn't for cripes sake. I am going to agree with the previous poster that this will only result in more binary only proprietary code. (Which is Bad).
<blush> Thank you.
USB support is there, but it's experimental. It at least works for the USB keyboard and mouse, and I believe there was an experimental audio module. It's in the same state as the Linux I20 modules--test 'em on a non-production environment and submit your bug reports or fix the code yourself and submit patches.
Cheers,
Joshua.
--jon. Postel is dead. May we all mourn his, and our, loss.
To application development that *USES* those device drivers, for example. Device drivers might be a fun geek hacking toy, and it's always nice to know whats going on at the lower level, but don't you think it's more important on a strategic basis for Linux developers to actually start moving into the Application development area rather than dealing with driver development?
It might seem like this at first, but when you lose the driver base, you're hosed. This bit us OS/2 users very hard. When your SCSI chipset doesn't work, your applications don't work, either. And having an ancient 16-bit driver that doesn't work with anything except disks does not count as support, even though some vendors (Rancho Technologies) thought it did.
The solution was to only buy IBM hardware or Adaptec hardware (until other drivers came out). So far, Linux has avoided that route.
Beware the binary primrose path. Maybe I'm just too much of a radical GNUer or maybe I'm just bitter after the OS/2 debacle--I just don't want to ever be burned by binary-only software again.
--jon. Postel is dead. May we all mourn his, and our, loss.
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?
The question is, what does the UDI do other than do this? All the UDI does is enable support for non-free UNIX platforms. We need to ask: what do *we* get for this? If all we get is the a bunch of binary modules, we've gotten nothing. If we get Linux developers to write to the UDI, wow. We have yet another API abstraction.
But look at what SCO (and probably Solaris x86) get out of this. They get free code without having to give anything back, other than more binary-only modules which are a Bad Thing.
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.
Actually, working with OS/2 has taught me paranoia quite well. The OS/2 driver situation was simply terrible, and there was nothing a user could do about it. I don't want more binary modules, and that's all SCO has to offer. If I want a proprietary, binary-only system, I do run a Unixware 7.0 system, and could use it. (CDE isn't half bad, by the way, with the exception of the dog ugly Motif).
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.
We have that now. It's just as easy to implement support for the current Linux driver scheme in a Unix or Unix-like kernel as it would be to implement the UDI--and there aren't any UDI drivers today, unlike Linux drivers.
Be very, very, wary of those who promise you FREE binary code. It's always a bad thing, especially with a freed operating system.
--jon. Postel is dead. May we all mourn his, and our, loss.
That said, I have an honest question here which hadn't occurred to me before. Doesn't that defeat the whole point of writing a UDI driver? Why wouldn't a GPL'd driver be usable on a closed system?
I've never been 100% clear on this point, which seems to be at the center of the RMS vs ERS issue. Is this what they are talking about when they use the term "infects" in relation to the GPL, as in "we have to be careful not to use code that allows the GPL to "infect" the code tree" etc.?
I'll sit back, listen and learn now
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
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.
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.
--jon. Postel is dead. May we all mourn his, and our, loss.
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.
--jon. Postel is dead. May we all mourn his, and our, loss.
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.
--jon. Postel is dead. May we all mourn his, and our, loss.
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....Open Source isn't the only answer -- but it's almost always a better value than the alternatives...