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 read the UDI spec before it was finished, and it also has a source development environment. It would be fairly easy to create a simple source code layer in the headers to translate the UDI calls into Linux kernel calls.
and besides - how would you rather your system was judged - by the number of obscure adapters it supports, or on its architectural merits?
The Linux hurd yells and screams and kicks because someone mentioned that they might want to help out on their own terms.
Sheesh
How many ways can I NO!! The quality of drivers would only increase if a company had to maintain one or, possibly, two code bases for their drivers. It's a simply rule of software engineering -- less code = higher quality. Also, to echo the sentiments of an earlier poster -- open source != high quality. Yes, it can be said that high quality products have been open source. It can not be said that all open source projects are high quality.
Binary or not, I would prefer drivers written by the company who designed the hardware. Even with open specs, the company who made the hardware knows it better than an outsider. They now about the little quirks in the silicon, and they understand where and how little optimization tricks can be had. It is not to say these insights can not be dervied from open specs, but why waste the time and resources.
Personally, I think all drivers for recent/ mainstream hardware should be written by the manufacturers. Why waste the valuable resources of the open-source community to support a company. If they want to make money on Linux, let them write the drivers and support it. To my mind, we have been a little too nice to these free loaders. Let them write the drivers and leave us to improve to the software. We should only be writing drivers for legacy or unsupported hardware.
Finally, I think the notion of a loadable driver is good thing(tm) -- even if it is implemented poorly in Windows. How can one expect to pentrate the desktop market if a user has to understand how to build a kernel when they get new hardware? While it is pretty easy for me as a developer, it is not for my mom(who is very good with computers). Plus, it takes too damn long. The Linux community is certainly cool enough and smart enough to make Linux hardware installation as easy as the Mac and as stable and powerful as Linux.
-MouseI agree that buggy drivers are a problem. Just look at all those Amish clogging up the roads with their horse drawn vehicles. Not to mention all the horse sh*t they leave everywhere.
Seriously, any bugs in a closed source driver will not only affect Linux users, but users of every system that implements UDI. HP, IBM, SUN, Compaq users are going to have the same problems, so there will be much more pressure on developers of the code to fix bugs.
This would be even more significant if MS ever implemented UDI (maybe for NT/W2K given the problems there are in getting drivers for some hardware on NT)
And the fix would only need to be done once.
MrCreosote Meow!Thump!Meow!Thump!Meow!Thump! "You're right! There isn't enough room to swing a cat in here!"
The spec talks about preprocessor symbols, etc. That seems to make driver/OS development in other languages difficult.
I would expect spec be a binary spec - like structure layouts in memory, how you interface the OS to the driver, etc.
On the other hand, this seems to encourage source drivers over binary drivers - or am I mistaken?
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?
Just today I was using gv to view the pdfs of the PalmPilot docs. Most people have that installed by default and it works just fine...
F0 07 C7 C8
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.
SMP is interesting because making the locking finer grained improves performance on SMP systems, but if you leave the locking compiled in for non-SMP systems, it reduces performance. If you're distributing your driver as source, you let the preprocessor take out SMP stuff for non-SMP systems. So UDI will either have separate SMP and non-SMP drivers, not support SMP, or have poor performance with one or the either.
UDI is emphatically not x86-only. They've already demonstrated prototype implementations where a UDI driver was recompiled unchanged to run on Intel Linux, SPARC Solaris, PowerPC AIX, PA-RISC HP-UX and Alpha Tru64 systems, among others...
It's not an evil Microsoft or Intel plot to seed the world with binary drivers. UDI started as an attempt by multiple Unix vendors to achieve cross-platform device-driver compatibility to help them all get more driver support. It's a technical specification, not a political one. It would be inappropriate and limiting to insist on Open Source implementations; they're trying to achieve maximum portability, not a political purpose.
Key point here: UDI only guarantees source-level compatability -- this gives driver writers an incentive to release the source to support more platforms and thereby work a larger market. Yes, they intend to support binary compatibility where it makes sense -- if the object module format (e.g. ELF) and CPU architecture are compatible, for example.
Many people seem to get outraged about UDI before even educating themselves on what it really is. They listen to RMS's paranoid delusions that it's all a plot to entrench the proprietary vendors, without stopping to check the facts. Go read the overview information at the UDI website and find out what it really is. Have an informed view rather than forming a mob. Think for yourself.
UDI is impressive technology. They really thought it through. It would be a shame for it to get shot down for political reasons that aren't even well-grounded from a political perspective in the first place...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I heard that there will be a lot of binary only driver now... is that the case?
Does anyone else find it ironic that they are releasing an 'open' standard using a closed format?
Technology . . is not any of these things. -Bruce Sterling
This is wonderful news! Now people will be able to use sucky hardware under linux too! Boy, we're definately going mainstream now!
--
Check out the binary plugable multi-OS driver (you dont need to recompile the binary if your running on the same platoform, but different OS) implementation of XFree86 4.0 and the pre server they released. It's what we should be awed about. :)
--
This is great news ...now the driver I'm working on using a dead protocol can now be considered dead as well...guess our clients will be beating on our door to meet these specifications too...I hate custom equipment...
any driver news (today) is bad driver news...
You say you want a revolution?
I'm sure Microsoft would obviously rather have hardware vendors code so some sort of Win-DD model, or preferably several Win-DDs, so that they have no time to support any other OS. But is it feasible for a third party to write a bridge between UDI and some Win-DD model, to allow UDI drivers to work under Windows? Perhaps more to the point, can this be done at acceptable performance? If this could be done, imagine hardware makers coding UDI drivers FIRST! It would let them capture Windows plus other platforms - the biggest market. Then at their option, they could follow up with optimized Windows drivers. But if Windows drivers are anything like other Windows programming, it may just be obscure and difficult enough to not bother with - just ship the UDI and save the resources. The improved availability of hardware drivers to the Open Source community might even be sufficiently valuable to merit taking on an "Open Source Windows project", if that isn't too oxymoronic. The downside of UDI is that it encourages binary-only drivers and may be used as an excuse to withold hardware documentation. First Post!!
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.
...but isn't UDI a Microsoft theory that was implemented by a group from SCO? If so, this might be something evil... could it not? :)
--
It is plain obvious that UDI is not going to help the Free Software movement, as RMS already pointed out long ago (http://www.gnu.org/philosophy/udi.html).
The tragic is that now, it's not even going to help Linux any more. Which is the most used *NIX on Intel platforms? Right, it's Linux. So, if a hardware vendor faces the choice of writing a driver for an Intel *NIX platform, which one is it going to be? Right, Linux! If Linux implements UDI, it's just giving them one more excuse of not GPL'ing the driver.
The only possibility this could help Linux (not Free Software) is that Microsoft implements UDI as its primary driver API. However, this is not going to happen.
bye
schani
Which isn't going to be much help if I'm running Windows, BeOS, MacOS etc...
As the OS that gets the most driver support at the moment is Win9x, it's important for any cross-platform driver system to work on it, as that (in most cases) will be the OS that drivers are written for first. If vendors can write drivers for it that also work on other OSes, then as long as it doesn't cost them much, they'll just take that route. They are much less likely to write drivers for a slightly portable system *as well* as doing a Windows driver.
Also, surely an XFree86 4.0 isn't going to help you much when you're writing a driver for a scanner?
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/
Binary drivers are totally worthless (Just take one look at SoundBastard Live) so why would anyone want to create a format that only serves to allow binary drivers?
IMHO UDI is evil and must be defeated, it would allow hardware makers to excuse the lack of proper documentation by pointing to their binary dog-piles.
"Look, just give us the specs on the hardware and we'll write the drivers on our own."
-- To dream a dream is grand, but to live it is divine. -- Leto ][
When I read the SlashDot announcement and browsed the webpages I was really enthausiastic.
When I browse the first comments I apparently have to limit my happiness, damn!
I always thought having portable (even if binary) drivers would be great, as it would help out 'starting' OSes (okay, so the Hurd kernel isn't exactly starting) as well as obscure ones to easily get wide hardware support.
It would allow for more varied OSes to emerge. I just hope the idea doesn't get killed over this bad implementation or whatever.
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!
please, pdf is just a fancy postscript file...
-- To dream a dream is grand, but to live it is divine. -- Leto ][
If this can be used as an excuse to distribute x86 binary drivers instead of source code, then this could retard the acceptance of modern processors and keep x86 on top. Wanna move that PCI card from your x86 box to your Mac or CHRP machine? There might not be a driver anymore... Bad news for LinuxPPC.
---
Have a Sloppy day!
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Cool, I saw this thing as I was about to start working on drivers for my own OS. Because most of its proprietary im cautious about supporting linux drivers - so this may help. But I have'nt read the UDI specs etc yet so i don't know.
UDI means "Hey, these Linux hackers seem to like to code for free! And look at how many drivers they've written! Maybe if we contribute three or four binary-only UDI drivers to Linux, they'll get hooked and then port all of their code to UDI and let us use it in our proprietary operating systems!"
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
UDI does not add run-time loadable drivers to Linux: Linux already has them, since version 2.0.
It's just that distributions haven't supported them very well until recently. In Red Hat 6.0, for example, the conf.modules file is very large, with auto-load statements for all kinds of drivers. It's finally usable by the masses.
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.
Microsoft is not a participant in the UDI specification. Take a look at the UDI project homepage to see who is participating.
---- "It is never too late to give up our prejudices." --Henry David Thoreau(1817-1862)
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,
Believe it or not, the "reference implementation" of UDI will be on Linux! That's right, Linux gets UDI for free, and everyone else has to write their own. Nyah, nyah, nyah, SCO! :->
Since I've read most of the the UDI specification (look for me in the
:-) misses the point of a portable
Credits of the 1.0 spec.) let me try to clarify some of the recurring
misinformation in these threads.
UDI allows either source or binary distribution of modules. How someone
chooses to release a driver is entirely their decision. Certainly the
most benefit of UDI is seen by those that release product as source.
Although Microsoft isn't a participant in Project UDI, there's certainly
nothing UNIX-centric about the spec. An environment could be written -
even by a third party - for those OSes.
The Linux driver interface, like every other driver interface that I
know of, doesn't solve a lot of the problems that UDI addresses. We
didn't exclude it out of snobbery; we are raising the bar. For example,
UDI allows efficient scheduling of drivers while allowing the details to
be handled by the OS and not the driver - no IPL changes, no sleeps, no
locks. It also has strongly typed interfaces with well defined address
and namespaces. Imagine a driver running in user space or even on the
other side of a TCP socket...Besides, nothing precludes any existing
driver interfaces from remaining.
UDI is certainly not only for IA32. Most CPUs that you would expect
(Sparc, PA, Power, Alpha, IA64, etc.) are represented and will have ABI
bindings published.
Drivers in UDI are implictly threaded. They don't know (and don't have
to care) how the OS schedules the code and how many processors are
available to do it.
There was concern about the spec changing over time. All the interfaces
(source and binary) are version controlled so a conforming environment
can run drivers as far back (or forward) as it can.
The spec publishes C bindings becuase those are the only ones defined
for most architectures. C++ ABI's are laughable at this point. The
suggesting of coding in assembly (have you tried to get a non-trivial
chunk of assembler through two different assemblers for the SAME
processor? How about different ones?
driver interface.
Please look at the white papers (if not the specs) at www.projectudi.org
before drawing conclusions. I read a lot of stuff that was just plain
fiction in these threads...
- Introduction to UDI (Technical White Paper)
- Functional Requirements (Simplified)
Note that the first link above is a PDF file, but it contains a good overview of UDI. The second link is a simple ASCII text file, so read it first if you have trouble reading PDF files. If you can read the PDF file, the entire contents of the text file is one of the sections in that PDF file.(Disclaimer: I'm not affiliated with Project UDI.)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I'm firmly in the "open source is good for everyone" camp. The problem is that the linux kernel interface for drivers is unstable and constantly shifting. The source interface shifts every few months, and the binary interface is hopeless. How come I have to make separate drivers for non-SMP and SMP systems? This is not a "source availibility" issue, I have the source to bash, gcc, et cetera, but I don't have to compile my whole userland myself, I can get my userland from a distribution because the kernel-userland interface is stable. UDI offers a stable interface to code to, and that's going to make it very attractive compared to the current interface.
Every time the UDI issue comes up on the Linux-kernel mailing list, there is a tiny bit of support and a lot of "don't-cares". Where is the carrot-and-stick that is going to actually make free software developers support this interface? UDI offers nothing to the driver writer except a different interface--an interface that won't change--a stable interface. In other words, an interface that will retain its faults forever. Even if there are different levels of the UDI specification, who's going to update old drivers? The UDI spec is not perfect--it will need changes over time. Try comparing a Linux driver from 2.3.x with one from pre-1.0 Linux, and tell me which one is more clearly and simply written. By the way, I downloaded a draft of the (big honkin') UDI core spec a while ago, but I can't find a released copy of the core spec. Where is it? I agree with RMS on this one--UDI is not instant free software victory and it's not Satan. But it's not something I'm terribly interested in programming for.