ProjectUDI spec goes 1.0 67
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.
Absolutely right! (Score:1)
And once again... (Score:1)
Sheesh
Re:Linux driver interface (Score:1)
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.
-MouseRe:And once again... (Score:1)
Infact, a closed device driver was one of the things that inspired RMS.
Buggy Drivers (Score:1)
I 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.
Now just a minute... (Score:3)
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?
Not really (Score:1)
Drivers are boring (Score:2)
Re:Hmm, UDI an evil plot? (NO.) (Score:1)
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...
Re:Why is this spec in C? (Score:1)
This hardly seems to encourage more binary drivers, since the source distributions will be usable on more systems, hence so will the hardware. This increases the size of the market, which is entirely in the interest of any vendor.
open spec / closed format (Score:1)
Great! (Score:1)
--
The hope is in Xfree86 (Score:1)
--
great... (Score:1)
any driver news (today) is bad driver news...
Linux driver interface (Score:2)
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?
Correct me if I'm wrong.. (Score:1)
--
This isn't going to help us (Score:1)
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
Hardly 'Portable' (Score:1)
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?
No it is not (Score:2)
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".
Hmm, UDI an evil plot? (Score:1)
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."
Hope for the Hurd??? (Score:1)
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.
Why is PDF a closed format? (Score:2)
--
pdf closed?? (Score:1)
Re:Linux driver interface (Score:1)
It also help developers. They would only have to--or at least should have to--test the driver on one OS for it to function on multiple OS's. As a developer, I can greatly appreciate how much easier it would be for testing. XFree86 v4.0 will have this feature.
UDI can only hurt linux.
Why? More drivers will be available to Linux and *BSD. This cannot hurt Linux for any user out there.
What would motivate them to release specs then?
Possibly good PR. Remember that hardware manufacturers had no reason whatsoever to publish specs for Linux, but they did so anyway. They did this even when there were very few people using it and Linux was an unknown name. Why will this make them change their mind?
I think people are being a touch paranoid.
Bad news for PPC, Alpha, etc (Score:1)
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!
driver support (Score:1)
UDI == Proprietary Unix getting free labor (Score:1)
Bashing UDI helps Microsoft! (Score:2)
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...
Re:This isn't going to help us (Score:2)
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!
Re:Bashing UDI helps Microsoft! (Score:1)
Re:Linux driver interface (Score:1)
Yes. They had a prototype implementation where identical source code could be built for Intel Linux, SPARC Solaris, PA-RISC HP-UX, PowerPC AIX, Alpha Tru64 (Digital Unix) and other systems. No changes, just recompilation. This is a source-level specification; binary compatibility is only available in certain situations where it makes sense...
If the module has to only be compiled based on hardware platform, you would get the benefit of all Solaris (Sparc) drivers being available to alternative OS's.
This is correct. Also bear in mind that Sun is one of the partners in the UDI project.
It still would cut down on testing. Have you ever done testing for multiple systems? It can be painful.
Since UDI is intended to carefully define exactly how the driver interfaces with the kernel, it should be clean to debug; drivers shouldn't be making assumptions about kernel internals, and incompatibilities between particular kernel and driver versions should be virtually nonexistent...
Re:This isn't going to help us (Score:1)
UDI is a multi-platform source-level specification. If you had a GPL-covered UDI driver, it would run on any OS with the proper UDI environment support, regardless of the platform. They had a prototype implementation running with identical driver source recompiled for Intel Linux, SPARC Solaris, PowerPC AIX, PA-RISC HP-UX and Alpha Tru64 (Digital Unix), among others...
Binary compatibility is encouraged (where reasonable) to avoid unnecessary recompilation, not to give proprietary vendors any advantage over Open Source developers...
Re:Now just a minute... (Score:1)
And, some would say that's bad enough.
For, if a driver is released binary-only right now, it ends up quite limited (witness SBLive vs. SMP), due to the way drivers must currently be implemented. Thus, there is now a drive for Creative to open the source to the driver, so that anyone can compile it into any arbitrary configuration of kernel.
Now, if SBLive drivers had been written to a UDI-like thing, then I would imagine SMP wouldn't matter. Thus, there would be no horde of SMP users (and people who want SMP) innundating Creative with requests. This would make it much less likely that Creative would ever, ever release the source.
That's all. This doesn't discourage open drivers, it just makes closed ones more acceptable to more people.
Re:Linux driver interface (Score:1)
You've got it backwards. UDI encourages binary compatibility where reasonable (e.g. same CPU, same load-file format, etc.) to avoid unnecessary recompilation of drivers. (Do you really think recompiling all your drivers for each Linux kernel release is a good thing? You should only need to recompile them if they were updated.)
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?
The same as always. Market pressure. Besides, they'll have an incentive to release the source to hit the largest possible market...
Linux drivers are already loadable (Score:1)
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.
Re:Linux driver interface (Score:1)
What you're suggesting is to simply make Linux's driver interface the Universal Driver Interface. But, Linux's driver interface has already proven to be unstable -- that is, it changes every so often. UDI is not a replacement for the Linux driver model, it's an augmentation to woo those hardware folk who still don't provide Linux drivers.
A great example is telephony boards: if it weren't for community groups like Open Telephony and the Linux Telephony project, there would be almost no support for telephony boards under Linux. And, most of these boards are supported via reverse-engineering, not by using vendor-published specs. That's a lot of community effort that would be better spent writing Linux telephony _applications_.
Windows in itself is not unstable. Third party drivers for Windows are what make it crash. Because of this, Linux will lose one of it's best assets; stability.
This issue will be handled through simple market pressure. If someone releases a buggy driver, it won't be tolerated in the Linux world like it is in the Windows world. The vendor will have two choices: 1) fix the driver, or 2) leave it alone and let its customers switch to a competitor's products.
Also, what happens when you want to run linux on non-x86 hardware? There goes linux portability.
Once again, UDI does not replace Linux's driver model, it augments it. So, maybe a Dialogic telephony board only works on x86 Linux and not Alpha Linux. Oh, well. At least we're better off today than we were yesterday. (FWIW, Dialogic is a good example because they've repeatedly refused to give away specs to their boards, even to people wanting to develop a binary-only driver. The only hope for Linux drivers at this point is something like UDI, because maybe they'll develop a driver internally for, say, UnixWare, that can also be used on Linux.)
Also, keep in mind that the companies behind UDI have their wagons hitched to other platforms than x86: UnixWare will move to IA-64, IBM is already on PowerPC, etc. What support does not exist for these today will eventually exist.
Going back to your earlier post:
Closed drivers are buggy and they always will be without the open source development model.
Have you watched the bug fix history of the Adaptec drivers in the Linux kernel? It seems like every other kernel update contains a fix to one or more of these drivers. That's some really buggy open source.
Re:Linux driver interface (Score:3)
It also help developers. They would only have to--or at least should have to--test the driver on one OS for it to function on multiple OS's.
Take for example FreeBSD. AFAIK FreeBSD has a module that allows it to run Linux binary kernel modules like they were it's own. Isn't this the same function that UDI is trying to accomplish? The developer could test their driver on Linux and know it would work on BSD as well.
Now, vendors could create binary only linux drivers, but the fast pace of linux development makes it impractical. Most modules need a recompile when you upgrade the kernel. That would require the vendor to have a recompiled driver for every incremental kernel version.
Huh? When linux was in it's infancy, no vendor published specs purely for the sake of getting a linux driver. Now, with 10M+ users, that's a pretty good reason to publish specs. It sells more hardware. More to the point, they will soon have to publish specs to be competetive. I wonder how many
Again, UDI can only hurt linux. Contrary to what most
Binary only drivers are bad.
Re:This isn't going to help us (Score:1)
On the other hand: As you might recall, Linux is a multi-platform operating system and I would not consider an Intel-only driver a full blown driver, so given a GPL-covered Windows driver (could you only cite one such driver???) I would have to convert it to the Linux driver interface anyway to make it run on my working machine, which happens to be an Alpha.
bye
schani
Re:UDI == Proprietary Unix getting free labor (Score:1)
And that would be a bad thing? I, for one, am encouraged by the UDI spec. Until such time as an "open-source" driver becomes available for a device that has a binary-only driver, I can use that driver and hence that device in the UDI environment of my OS-of-the-day.
The only thing I found limiting about the UDI spec is the lack of flexibility in configuring instances of a given driver, and the fact that they made no provision for on-the-fly configuration of various driver settings.
Maybe UDI-1.1
--Corey
Re:Hmm, UDI an evil plot? (Score:1)
Clue Stick (Score:3)
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.
Re:Linux driver interface (Score:1)
Why should they have to be the ones to give in and include Linux driver compatibility? Devil's Advocate: maybe Linux should include SCO driver compatibility even though Linux has more driver support already than SCO.
Now, vendors could create binary only linux drivers
They can do that already. UDI will not change that fact.
Now, with 10M+ users, that's a pretty good reason to publish specs. It sells more hardware. More to the point, they will soon have to publish specs to be competetive.
Or they could write their own binary-only driver using Linux's module interface. They don't have to publish anything to be competitive. I think they might do it for good PR though.
I wonder how many
My next machine will have one of these cards, but I am basing it on how well these companies support XFree86. Source or not, I like to see the companies say they support their product on the OS even if that means only the specs are public.
Third party drivers for Windows are what make it crash.
Also, what happens when you want to run linux on non-x86 hardware? There goes linux portability.
Is UDI only for x86 or was it designed for more than the x86? I realize that the module would have to be compiled for each hardware platform, but is the interface the same?
If the module has to only be compiled based on hardware platform, you would get the benefit of all Solaris (Sparc) drivers being available to alternative OS's.
It still would cut down on testing. Have you ever done testing for multiple systems? It can be painful.
Binary only drivers are bad.
I never considered them necessarily good.
NO! (Score:1)
Re:This isn't going to help us (Score:1)
All right, then riddle me this: why is it that SCO's UnixWare and OpenServer operating systems support some hardware that Linux doesn't?
Yes, I realize that Linux has broader hardware support than SCO systems do, but there are also whole categories of hardware that aren't well-represented on the Linux platform. Two examples are telephony boards and RAID systems.
Re:Clue Stick (Score:1)
If you have a choice of boards, why not find the one with the most stable driver and use it? If it comes to a run-off, pick the one with open source.
This is not hard....
UDI and funding of opensource development (Score:2)
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
Re:So, who is actually going to implement UDI? (Score:1)
Re:Why is this spec in C? (Score:1)
If the source level API relies on preprocessor symbols, then how does one implement drivers in, say, assembly?
The spec needs to be an ld level ABI/API, such that the symbol names are garunteed to line up.
John
Re:This isn't going to help us (Score:1)
John
UDI from a contributor (Score:1)
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...
Re:Why is this spec in C? (Score:1)
That is, you might highly hand-optimize a UDI driver in assembly for Pentium using the ELF load format. That's all well and good if you're using that platform, but you aren't doing a bit of good for someone running with a SPARC platform using a.out load format, for example. Thus, you should have a general-purpose C version of the driver for non-optimized platforms.
While a hand-optimized assembly driver could clearly function under a UDI environment, I'm not sure if it officially qualifies as a UDI-compliant driver if it's not in portable C code. Even so, it's clear that it could be made to work if enough is known about the particular platform and UDI environment implementation.
UDI Basics (Why it's NOT an evil plot...) (Score:1)
- Introduction to UDI (Technical White Paper) [sco.com]
- Functional Requirements (Simplified) [sco.com]
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.)
Re:This isn't going to help us (Score:2)
>are actually taken from the Linux kernel
Which is why it's wrong to refer to Linux/HURD as simply HURD
[duck]
Re:Hmm, UDI an evil plot? (Score:2)
Re:Linux driver interface (Score:1)
If the masters of linux are forward-thinking, then the linux kernel will contain a UDI driver model. Having copious drivers available can only be good for linux. Also, dropping the tight binding between the kernel and the drivers would be an architectural improvement (it's shouldn't be neccessary the recompile all of the drivers with the kernel).
The people who contribute to linux can't afford to compete with microsoft (who can afford to rewrite drivers with every windows version) by continually reinventing the wheel
Re:Clue Stick (Score:1)
Stable driver binary interface (Score:1)
So, who is actually going to implement UDI? (Score:1)