Slashdot Mirror
ProjectUDI spec goes 1.0
PHroD writes "Project UDI today announced the release of the UDI (Uniform Driver Interface) 1.0 specs. This hopefully means great strides in new drivers for all our favorite obscure hardware! " They've got most of the 1.0 materials out-grab the official specs, in PDF, from their site.
I see a lot of people saying how this is a Bad Thing because it encourages binary-only drivers. Now, perhaps I'm just clueless, but how the hell does it do that? It's nothing more than a standardized API, kind of like X, or glibc (if you count that as an API, which I do), or any number of other bits of Linux software.
I know, I'm probably begging to be whacked with the Clue Stick, but could someone please enlighten me on how open standards discourage Open-Source?
Writing drivers (and here I mean "drivers" in the strict sense of the software that most directly controls a device, not in the loose sense that includes things like filesystems and protocol modules) is one of the least creative forms of kernel programming. Providing a framework for more portable drivers will reduce the development effort expended on drivers and will free up many developers to do other, more interesting, things...and that, to me, is more important than open vs. closed source.
Slashdot - News for Herds. Stuff that Splatters.
UDI encourages binary only drivers which is a Bad Thing. If other OSes want universal drivers, they need to implement Linux driver compatibility. It shouldn't be the other way around. UDI can only hurt linux.
Closed drivers are buggy and they always will be without the open source development model. It's hard enough to get specs for hardware now. Imagine if the hardware vendor had a UDI driver. What would motivate them to release specs then?
--- A Jesus Fish eating a Darwin Fish only proves Darwin's point.
See subj:
This is the most devious move against linux, bsd, solaris and MacOS X that SCO could invent. Now everyone will get an excuse "We have a driver but we do not support it for XXX. We support XXX and do not disclose specs".
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
The entire specification is published and freely redistributable, and there are free readers and writers. What else do you want from it?
--
Xenu loves you!
Enough hysteria! Linux developers should be supporting UDI, tearing it down. This technology is Microsoft's worst nightmare! Think about it. Why is Windows used so much? "Regular people" use Windows because of driver support and application availability. But if you ask such "regular people" about whether they like using Windows, many of them describe all sorts of frustration with nonintuitive UI's, random crashes, and pointless reinstallations.
Windows retains its stranglehold primarily through network effects, and Microsoft depends on that fact for their very survival. Remove those supports and Microsoft will become very unsteady indeed when it can only compete on the basis of actual quality. If UDI is successful, it has the potential to remove fully half of the artificial support propping up Microsoft's array of shoddy products. Like Wine, UDI has the potential to level the playing field, which is good for everyone but Microsoft. Unlike Wine, with UDI, Microsoft didn't write the rules.
UDI was designed from the ground up, originally with Unix systems in mind. It is source-level API, and binary compatibility is a secondary concern. As far as I can see, the main reason to specify binary ABI bindings for UDI appears to be to discourage unnecessary recompilation. Should you really need to recompile your drivers every time you upgrade your kernel, or should the drivers just work with any kernel version? Should you really need to upgrade an otherwise-working kernel just because you need a new driver, or should you be able to compile just the new driver for your existing kernel and load it dynamically into the system without even rebooting? UDI can help decouple dependencies between kernel versions and driver versions and thereby enhance stability. This is a good thing.
Microsoft would not want to support UDI for exactly the reason Linux enthusiasts should support it -- UDI levels the playing field between different operating systems. For UDI to really take off, it would need to be supported under Windows as well as Unix. While Microsoft could implement if, they won't unless and until the market forces them to, much as the market forced Microsoft to support the Internet. (They tried to create their own Microsoft "standard" version, MSN, but that was a dismal failure.)
A third party will have to create a UDI environment implementation for Windows first. That will encourage hardware vendors to stop writing Windows-specific drivers and only write UDI drivers to hit Unix and Windows markets with a single implementation. Since UDI is a source-level specification, it would be in their best interest to release the source to their UDI drivers to penetrate a larger market with no additional effort. This would be good for the industry, but bad for Microsoft; they don't want it to happen.
The Open Source/Free Software community should make every effort to ensure that it does happen -- in particular, writing an Open Source UDI environment implementation for Windows would be very valuable to all users of alternative operating systems. Windows 95/98 is the critical target platform right now, but UDI environments for Windows NT, and even DOS and Windows 3.1 would also be useful, if they could be done.
Adding UDI support to Linux, FreeBSD and other systems should be a top priority. Porting existing drivers from Linux and FreeBSD to UDI should be the next priority, followed by the usual work on stability and performance. Ideally, using the native Linux driver interface should provide no advantage over the UDI interface, and thus the UDI drivers should be preferred. (This will take some time, but it should be the goal.)
It may sound like blasphemy to advocate abandoning the Linux driver interface for UDI, but it's not. I've seen comments that the Linux interface should become the de facto standard. At best, that just means replacing one de facto standard (Windows) with another (Linux). Of course, that can't even happen without displacing Windows by Linux entirely first, since making Windows run Linux drivers would probably be much harder than making Windows run UDI drivers.
UDI would be good for Linux. Kernel developers could concentrate on kernel features and stability without having to worry about the drivers. Driver developers could concentrate on driver features and stability without having to worry about the kernel. After the necessary learning curve and initial investment, it frees everyone to focus on the work they need to focus on without having to be distracted by compatibility issues.
Also, the kernel side of a driver interface only has to be implemented once, in the kernel. The driver side, on the other hand, has to be implemented many times. UDI places more of the burden in the UDI environment (the kernel side of the interface implementation), rather than in the driver itself. It makes more work to implement the kernel side, but it only needs to be done once; it's an investment returned many times over by the simplification of the driver side.
UDI drivers don't have to concern themselves with endianness issues, or with whether or not to disable interrupts, or with multiprocessor synchronization, or even with the possibility of running on an I/O processor rather than the host computer. All that sort of thing is handled by the environment, which means that UDI drivers should be easier to write than Linux or Windows drivers, because they can assumptions which are guaranteed by the specification. It should also make them less prone to bugs, since simpler code is easier to debug.
As for the concern that having sloppy drivers could hurt the stability of Linux, I must point out that this is an existing danger. Some drivers are more stable than others, and you're always better off using hardware with a well-supported driver than an obscure one. However UDI actually provides a solution to dealing with buggy drivers -- there is no assumption that UDI drivers will run in a privileged environment; there's no reason the kernel couldn't use memory protection techniques to protect itself from buggy drivers as it protects itself from buggy user programs. This leads to a valid potential concern about performance, that the context switch could be expensive. This is a classic performance vs. stability tradeoff.
However, it's easily solved -- have both privileged (fast and crashable) and non-privileged (slower but uncrashable) modes, and let the system administrator decide which mode to run each driver in. System administrators could then make their own decisions on the tradeoff between performance and stability, based on their own needs and experience. This could mean even greater stability than Linux already enjoys. Who can argue with that?
The concern about proprietary UDI drivers being released only as binary is a red herring. This is already possible; binary-only Linux device drivers can already be distributed. Since that only covers certain platforms, there's still a large segment of the market being ignored. If a hardware company makes a PCI card that could plug into an Intel Windows, Intel Linux, SPARC Solaris (newer, not sbus models) or Alpha Tru64 system, releasing a UDI driver as source could cover all those platforms with a single development effort. Narrowing the market unnecessarily by releasing only binary drivers could be done, but it isn't in the best interests of any proprietary company; they want to penetrate the largest market available.
UDI could change the largest market from "x86 Windows systems" to "any UDI-compliant platform", as long as Windows is supported. And then the proprietary companies would release source code despite themselves, solely due to selfish decisions to pursue the largest market. This would help to break Microsoft's stranglehold on the industry and provide much more timely hardware support for not only Linux, but also FreeBSD, NetBSD, BeOS and any other OS that ends up with a UDI environment.
UDI also opens the door for new operating systems to compete with established ones (yes, including Linux), without having to waste time implementing the device drivers necessary for acceptance. This will lead to more competition on OS features rather than simply driver support. Competition is good; it helps people focus and create higher-quality code, and encourages steady improvement. If the current duplication of effort for driver development is eliminated, we'll be more likely to see cool new OS features available sooner...
All this UDI bashing is counter-productive. Don't blindly accept the rumors flying around Slashdot. Look at the UDI website and see for yourself. UDI is not a Microsoft initiative. (Like I said, UDI is decidely not in Microsoft's interest because they want to maintain their monopoly.) UDI is not a sneaky Intel plot. (Intel is only one of many supported CPU types, and they appear to have joined the project more recently than most.) UDI is not designed to enable proprietary binary-only drivers, although it won't take special measures to block them either.
UDI is not tied to any particular platform; the model works with single-processor or multi-processor systems, on single-tasking or multi-tasking operating systems, on big-endian or little-endian systems, on the host CPU or on a dedicated I/O processor, on an Intel x86 or on a SPARC or PowerPC, etc. This is good technology, and very well-engineered, and we should applaud it. Yes, it's still new; it probably will be improved futher in the future, and performance is still an open question. Nevertheless, it's the right direction to be heading...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
People could run free GPL-covered Linux drivers with Windows systems.
People could run non-free Windows drivers on GNU/Linux systems. However, I see much more options:
People could run free GPL-covered Windows drivers with Linux systems. (There is Windows GPL development as well you know).
People could free GPL-covered drivers on GNU/Hurd systems. (as I mentioned earlier, would it not be great if the Hurd has wide hardware support).
People could free GPL-covered drivers on GNU/FreeBSD systems (If I look at another article of today, they probably wouldn't want to, so....)
People could free BSD licensed drivers on GNU/Linux systems
free drivers on Mac, free drivers on (God help us) OS/2, so people can keep using their old junk. etc. etc. Of course, there will be a lot of binary only drivers. But as long as the UDI framework is open, I don't really care. If Eric Raymond is right (he might be), Open Source versions of some of the same drivers will kick the binary-only versions' butt!
UDI does not encourage binary only drivers , nor does it discourage them. The goal of UDI is to provide a consistent API between drivers and kernels across all Unices (and Windows?). This is a good thing as it reduces the ammount of work that has to be done by a driver writer. Write once, cross-compile and you're done (or so the theory goes)
I've written device drivers for Windows, RTOSes, and Linux, and device drivers and any kernel level components are rather complex beasts. Making them easier to write will only make more harwdare accesible to different OS users.
This seems like a helpful addition to the driver design process but it kinda bursts my bubble about open source development.
I always thought it would be viable that open source development of the 'non-sexy' features which are often claimed will kill open source would be funded by the device manufacturers. These manufacturers gain nothing by keeping their drivers and code proprietary and before this specification lost potential buyers.
These companies (maybe even places like apple) would release upgrades/enhancments to open-source projects to encourage users to buy their hardware ("You can now run linux on a sun buy sun" or "Buy sun with linux now supporting feature Y"). The nature of the GPL would requie these developments be GPLed as well making everyone better off (people get better software, hardware makers get people to buy hardware, programers get paid to code open source).
With a specification such as the UDI things get a little more hairy. A hardware manufacturer can employ coders to write a binary only enhancment to linux (say hardware driver) and gains the same advertising/usership upgrade as if he had coded the driver in opensource. In addition he forces his competitor to spend resources redoing all the work when his competitor wants to do something similar.
In this case everyone loses. It costs hardware manufacturers more money (they can't use similar code already out there on the net). People lose having proprietary hardware. And more programers are "wasted" repeating the work of others when they could be gainfully employed doing new work.
This is not to say the UDI is bad just wanted to raise some questions about the effect of this, and hardware companies in general, on the future of opensource development
Marriage is the "pseudo-ethics" that cloaks the messy truth of sexuality in the raiment of propriety -- it's "Don't Ask,
>As a matter of fact, most drivers for the HURD
:)
>are actually taken from the Linux kernel
Which is why it's wrong to refer to Linux/HURD as simply HURD
[duck]
Or, more likely, 4 of those developers would be laid off.