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.
It turns out the main difference between the $50 entry level card, the $100 midrange card, and the $200 or $300 high end card is what software the driver downloads to the DSP on their card. They think that if people knew too much about how their cards worked, people might start making the $50 cards perform like the $300 cards.
I don't know how many companies do this kind of thing, but if its common, I'd expect winmodems, winprinters, and many sound cards to stay closed.
A binary module is NOT part of the kernel. Nobody has any right
to say anything about it. Period.
You can decide if you want someone else's binary module
to be part of your linux distribution.
big comp. like MS prolly has its finger in lots
of pies, so that if some of them take off
it can be quicker to get on the bandwagon and
make $ off the trend. so they might be 'supportive'
or at least interested in several different competing standards/
products simultaneously.
It would help MS in one area. It would mean better device support for NT.
The spec for the binary formats is not yet done, and with a bit of whining about being able to use your gadget in future hardware we could make vendors release the source with the binary releases (and use only the source on Linux - I really do not trust closed-source always-crashing things like Netscape ;-) )
Well, someone had to say it.
I think UDI is inspired more by the fact that no one wants to support SCO anymore than it is by the needs of anyone besides SCO. After all, SCO is the reason Adaptec 1542s were still available long after they were beyond obsolete (for a *long* time, none of the 2940s worked, and trust me, installing SCO with a newer 2940 can be a bitch).
I'm not trying to bash SCO here, but point out that if people don't write UDI drivers, how else is SCO going to support new hardware?
I wouldn't be surprised if a UDI interface for OS/2 magically appears, either.
gv is a nice frontend to ghostscript (which supports PDF):
http://wwwthep.physik.uni-mainz.de/~plass/gv/
ghostscript comes with almost every Linux distribution, and is undoubtedly in the *BSD ports/packages/whatever collection
xpdf is a free PDF viewer. There are patches to support encrypted PDFs but due to the U.S. government's anal-retentive stance on crypto export controls, you have to download it from outside the U.S. The main site is at: http://www.foolabs.com/xpdf/
Also, Adobe's Acrobat Viewer doesn't cost any money, though it is closed source:
http://www.adobe.com/
Relax. Parallel ports are still used by many in the embedded market. As long as there is demand, you will be able to buy parallel-port plug-in cards at your local CompUSA.
-- Guges --
This makes me wonder: wouldn't it be cool to have Windows Device Model
compatibility as a module. This'd be better than wine.
If a binary driver is unstable under Linux, then it will also be unstable under Solaris/x86, SCO, etc.
I hate to break it to you, but third-party drivers in general tend to be very unstable for ANY operating system. Why should we expect their quality to suddenly improve? Linux has by far the most stable device drivers of any OS I have ever used. Let's keep it that way.
-- Guges --
Uhm.. No..
Thats the purpose of DirectX, Direct3d, etc.. It essentially turns windows into a fancy framebuffer.
The last dos-based game was about 2 years ago. People don't want to write their own drivers for every single game, simply because VESA performance sucks.
First off, without source code, folks won't be able to debug the driver and send in patches. This would result in kernel space bugs, which in turn means the OS becomes less stable. That is not good.
This AC did not investigate -- someone confirm, does the spec require releasing source code?
Second: do take a look at ALSA (Advanced Linux Sound Architecture). Eventually it will be in the Linux kernel, hopefully in 2.3.
Trident, my favorite video card manufacturer from back in the day, manufactures a fantastic sound chipset. Recently they wrote a GPL'd driver and contributed it to ALSA.
--ac
The only current way is to do abstraction. I believe there will always be a need for portability (with C/C++ of course). I don't see every system using the exact same API with exact same header files, etc. In DOS/Windows world you got away with using nice APIs, system calls, whatever but in a Unix based world you have to consider portability. A language like Java (but is more machine-binary rather than independent-binary oriented) might be the answer. Until APIs become part of the language spec itself.. I don't see it happening. Simply because people do not like to rely on other's APIs (an ego thing?). APIs are reinvented everyday. Its not always bad though. Sometimes a reinvented API will bring an easier way to access devices. But then you have the issue of cluttering a system (which I've seen a lot of cluttering happening in Linux) and having to download many libraries for programs to work correctly.
Tim
Sound cards and any other sound hardware/software have very spotty NT support - you will do well
to study the newsgroups before parting with
cash... even where drivers exist they often
turn you into a crash test dummy...
I don't get it; if the driver is uniform, why bother having a driver at all? I understand that general function groups can be generalized (eg "reset", "shutdown"), but *some*thing has to be hardware-specific - that's why there's a driver in the first place. How does UDI differ - other than topographically, and possibly by making all the function names conformant amongst themselves - from current drivers? The only thing I can figure is that the driver provides some kind of capability list - but then the app has to be changed every time a capability or parameter changes. Please, buddy, spare a clue?
UDI adds a layer of overhead. It also doesn't
handle things like nice ISA probing Linux does.
It doesn't handle parallel port sharing, and
basically would reduce Linux to the level of the
old SCO Opendorktop.
UDI is still about 6 years behind reality.
Alan
>Because there are flaws in Linux like any other OS.
...
This dilutes our ability to correct them - if we don't know what's causing the problem, thanks to a binary-only release, we don't know if it's linux or the driver that needs amending. Linux is in a permanent state of flux. I like it that way - it can evolve.
>it works buggy on Solaris it will Work buggy on Tu64 and Linux
Not necessarily. They may be more/less permissive about memory protection etc.
I really don't think binary-only releases are viable across incompatible CPUs.
Hopefully this UDI thing will die, and HW manufacturers will become truly open. We can hope. - and - *we can write them about it*
Please be polite. A printed letter tends to achieve far more than an e-mail. (I doubt hand-written letters are going to be legible, given the technical readership here)
devfs is great!
I switched to linux from the amiga, and device handling seemed rougher, not better, than the amiga devs:#? hierarchy( don't forget, BeOS==AmigaOS done right). Of course, the other advantages of linux far outweighed the rough edges, and it is clear that the free software development model, as shown by this great devfs, can merge the best bits of all the other OSes into it ( where's Random 10, the GPL Plan 9 clone, though...)
devfs really should be in there. All those numbers in use currently annoy me. However, I would worry about security. Maybe this is why Linus has not incorporated devfs into the kernel yet - he's waiting for the FreeBSD folks to work out the rough patches of devfs for the first few versions.
Maybe 2.3 will see it, eh ?
I agree with your first point; Nvidia has every right not to release source for their drivers, and to protect their intellectual property. If they abstracted their hardware interface a bit, then open source drivers wouldn't pose a risk to their intellectual property. Then again, it would add to their time to market, and face it, the shelf life of a video card isn't much longer than the shelf life of eggs or milk nowadays :)
:)
However, I'm not sure about your second point. I don't see much of an ATI RAGE128 boycott going on among Windows users, although the drivers are (ahem) less than stable. I know one guy who returned his and bought a TNT, and is disappointed because the TNT is soooooo obsolete
Anyway, as long as they leave VGA text mode support in their cards, Nvidia will have no reason to consider UDI anyway (since a userspace solution will do).
not bloody likely. look who's pushing the standard.
Case 1. If a given binary kernel module is not a derivative work of the kernel then it doesn't matter what Linus says. The module is not in violation of the kernel GPL.
Case 2. If a given binary kernel module is a derivative work of the kernel, then it requires the permission of everyone who owns copyright on part of the kernel. Linus doesn't own the whole kernel, and so it is not in his power to grant GPL exceptions to allow things into the kernel.
Especially for things like video cards where gamers want the absolute fastest graphics card to play Quake 666 or whatever, a driver that a UDI middleman will be slower than a 'real driver'. Heck, this is why many games today *still* run in DOS mode. Games don't want windoze in the way, they want to access the hardware directly.
As far as I know, it's all just magic. What happens when we run out of major numbers? Is 255 the limit?
I reiterate -- third-party device drivers are already buggy for other OS's, and we have no reason to think this will change. Why should we import buggy device drivers to Linux?
-- Guges --
3dfx cards do not have open specs. Until recently, they were completely closed. They are now partly open, but many of the good parts are still closed.
>driver images is a bad thing? As long as they run
>on all platforms, I dont see the problem.
I don't think it's necessarily a bad thing - sure it breaks GPL - but consider two things:
- if UDI flies someone's gonna implement it for the Linux kernel - if not the normal kernel people then some card vendor who's already written a bunch of UDI drivers and is faced with either reimplementing them all for Linux or doing a UDI implementation
- true binary drivers leave us with the possibility of a Mac-style card driver where it's all in ROM on the card and 'driver installation' solely consists of plugging the card in the slot - the kernel finds the UDI driver from the card's ROM and loads it at boot time automatically (yah!) sadly my quick read of the UDI docs doesn't seem to include this possibility
Now putting on my some-times multi-platform hardware designer's hat - this is a god-send - currently we're faced with support for DOS, Win31, win95/98 NT, Linux etc - you can see why Linux often gets left out, or left to last - and we techy guys don't get to decide - that's up to the marketting weaselsIs there a free pdf viewer? Or is there a version of this proposed standard available in a format that has a free viewer?
Huh? What games today run in DOS mode? I can't think of a single game that came out in the past year (probably more) that ran in DOS. And as far as a 'real driver,' what about DirectX and OpenGl - same type of interface, but widely accepted, because game programmers can't program for every architecture out there.
In that case wed soon have cool MS certified drivers for Linux - which would be opensource - to Microsoft at least.
Just who the hell are you to say that it must do (this) or die?!
Another level of indirection, especially one so generic, seems to be anti-productive. The url listed shows a page that suggests (from the list of pdf files - no, I haven't read them) that each type of device - network card, SCSI card - will have its own UDI-type driver. Seems like it would slow everything down an order of magnitude, the kernel having to do *every*thing hardwarily thru generic interfaces ...
Apart from the fact that its orginated by Intel, I'm not sure I see what this would do which you couldn't already accomplish with Open Firmware.
Well... How can you, yourself, fix a buggy driver then ? If you don't want to, then how do you expect a Free Software developer, who has made linux as reliable as it is today, to be able to?
;-))
What if the company that manufactures your hardware, that your company has bought 1000 units of, decides to stop supporting your hardware? (probably to "encourage" you to upgrade to whatever new hardware they've just brought out)
If there's binary only drivers, unless you're a northern european (legal there) with a big reverse-engineering budget, you're working to the HW company's agenda, not your own.
All well and good, you might say, just don't use hardware with closed-source drivers. But it's not that simple, thanks to hardware patents, sometimes there is only one device to get the job done. Seriously, most of the time, the driver source does not reveal enough about how the hardware works to give competitors an advantage, and even in situations where it might, such as 3D graphics cards using custom VLIW instrucion sets, the release hardware is 1 to 2 generations behind what the company is currently working on anyway.
And then there's dilution of support for truly open standards. A non-contributing end-user of a free OS might shrug his shoulders at all of this.
When you use Free software, you are making a sort of bargain. You're using the work of many other people, that they have selflessly opened up to you, basically because you're expected to share your work with them. For years, chances were you were actually going to do some sort of development work.
This works well in academic cricles, but when big business and self-interested end-users get a foot in, you can suddenly get a huge body who take while giving very little back.
This need not be true. The average windows user is held back by the OS - expose them to linux/bsd and they "flower" - suddenly they are free to do whatever they want with their computer. I have seen this happen with several new users recently eg. one had spent the past three years basically using his computer for word-processing. He wanted to know what this linux thing was ( he saw my flashy desktop), and I offered to help him make his system dual-boot. I left him with a pretty vanilla RH 5.2 + KDE installation, came back two weeks later, and he'd gone kernel 2.2, got a new CD-writer up and running, and a zip drive (mind you, I had advised LS120), without my intervention at all. He has started various coding projects.
All this in a matter of weeks from point-click-drool.
As for companies, they too can benefit from open development - if they do it right. IMHO, the APSL v1 is not quite there yet. ( and I had issues with the mozilla lisence, and the QPL, but that's another matter)
I believe the Open Source folks should take a firmer stance on such things - I understand their enthusiasm for getting the big name players in, though.
Open Source principles could be extended to far more than software production. Maybe someday they will. True Free Software principles, too, but that will take a whole lot longer.
And, while we're at it, can we please switch to a first-to-file patent system, at the very least, instead of being the only country to operate the first-to-invent system, which is incredibly open to abuse. Damn you all - I'm XORing all my gfx from now on...
Consider what will happen a few years down the road. We would have no control on how drivers are implemented. We would have increadibly buggy slow blaated drivers and would be powerless to fix it. Linux would bocome like NT slow and bugy
If we thumbed our noses at UDI then we would be the ones in control. If linux gained enough market share it would cost hardware makers too much money in lost sales for them not to release thier specs. In this scenerio we would have compleate control over the drivers.
> Because a driver runs in kernel space
DANG!!! We need the HURD, or take some QNX concepts, and roll them into linux.
And it looks like it's frozen anyway, what with the 'no seriuos changes' bit.
> Parallel port as a system interface is also going a way real fast.
Shame. the parallel port is great for hobbyist hardware projects - It's simple to program, easy to hook up to external TTL, and allows you to roll your own hardware solutions - it's used extensively for all manner of one-off control systems in the small-time mechanical engineering industry.
Obviously, big business wants to kill it. It empowers (icky word) the user - and we can't have that, now, can we ?
All the same, USB looks fairly hackable, so the good ol' par port may not be such a loss.
Unfortunately, the mentality of these hardware companies is to withhold all information because it has more use to them as a bargaining chip. Look at all the unreliable and flaky drivers out there for Windows that never get fixed and updated... people just are forced to use them anyway.
1. Windows is the dominant OS. Any hardware vendor who writes a windows driver is guaranteed 90% of the market. It's not cost-effective to write a UDI (or whatever) driver to get the other 10% of the market.
2. Suppose M$ would support UDI. Oh, wait... why would they do that?
3. Generic (UDI) drivers might be slower then OS-specific drivers. I don't think it is necessarily the case, but it is very possible.
put down that crack pipe. Creative most definately DID NOT allow creation of open drivers. they hired someone to write binary only drivers, which is a bad thing, I will never buy any hardware which is not supported with a Free driver. (Freedom, not beer)
And of course the complaint itself was in error as
UDI is cross platform.
"You know you want me baby!" - Crow T Robot
And with UDI you can write a driver for it which will work on all platforms that support
UDI, which could include all free platforms.
UDI is a good thing... Don't confuse it with
trying to coerce vendors opening their own
drivers.
"You know you want me baby!" - Crow T Robot
"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."
...
I find this to be somewhat narrow-minded. If all we get is binary device driver modules, that's not nothing.
That's an opportunity to MOVE ON.
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?
Generally speaking, that is. There will always be lower-level work to be done, but organizing device driver development is a good thing
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
The problem is (and remains) that in order to make corporations happy with Open Source, OSI is always compromising. To those of us who have philisophical and moral ties to Free Software, these constant compromises and exceptions cut like a knife. With each new compromise we feel we're losing a little more. OSI can never represent me until it understands this.
Folks with a tradition of posting high are now getting high initial values.
I don't like it, it's Malda's decision to make...
Because a driver runs in kernel space, and can affect performance, and stability of the whole operating system.
If I find a bug in one of these drivers, the hardware maker has my hands tied.. I can't fix it.
Hardware maker should be encouraged to release hardware specifications! This is going in the opposite direction from what we want.
I for one hope Linus and Co. don't accept any patches to support UDI in the kernel. We have to stand up for freedom.
This could very well cause a kernel split, and that bothers me, but I think most people would still use Linus' kernel if he decides to take a stand on this issue.
Does anyone have any links pointing to Linus' viewpoint on UDI?
Run that by me again? Why would someone do this? Any decent videocard is supplied with an OpenGL ICD. What would be the advantage of emulating OpenGL, when the real thing is available?
Mathijs
For hardware vendors targeting a small section of the server market, the UDI is still pretty interesting. For instance, it would allow companies like Mylex and DPT to write only a single driver for their RAID controllers. In the mid- to high-end servermarket you see a lot less NT boxes.
On the other hand, you would expect both performance and stability from a product like a RAID controller (what other reason is there to use one). Personally, I think a Linux `native' driver will be able to provide better performance and stability than the UDI drivers. If a hardware vendor can develop a single UDI driver and distribute only the binary, where's the incentive to provide access to external driver developers to specifications? I fear the UDI will give hardware vendors an excuse to stop providing support to Linux driver developers.
Mathijs
Personally, I'd prefer to see open specs for hardware... the recent ATI reversal of opinion is a prime example that suitable pressure can be exerted to make that a reality in many cases. However, I expect the common linux user would be perfectly happy with an encapsulated binary only driver, as long as it lets them get work done. That's the slippery slope, of course; once we accept what's "good enough" to do the job, we'll lose the opportunity to shoot for something better.
--
rickf@transpect.SPAM-B-GONE.net (remove the SPAM-B-GONE bit)
"People will pay big bucks for the luxury of ignorance."
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).
Chris DiBona
--
Grant Chair, Linux Int.
VP, SVLUG
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
This question was posed at the Intel Developers Forum. The answer was to the effect "they could, but we haven't heard from them". Will MSFT participate, don't bet on it.
concur. devfs is excellent.
/dev now shows me only the devices for which drivers are loaded. i like the way i don't have to remember which scsi device /dev/sdb is, especially when i've hot added/removed something.
been using it for a good while now. it works well, it's backwards compatible. i like the way ls
just wish it could be rolled into 2.2... would make things a lot easier.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Binary only drivers have the same problem as any closed source software. I.E., if it's broke, you can't fix it. You can't improve it, or enhance it.
I think you're missing the point here, Bruce. The idea is not to divide the world into "them" and "us". It's to create high quality software that we have the freedom to modify and redistribute as we please. As such, LGPL would be a much better license for UDI drivers. Otherwise, we'll end in a situation where there have to be two (or more) UDI drivers for each device -- one GPL (for us) and one non-GPL that can be used by the proprietary Unices.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
All of that is 100% true. But companies will still ship buggy drivers. They do it all the time on Windoze. Why do you think UDI would be any different? If they can't be bothered to ship bug-free drivers for 90% of their market, they're sure as hell not going to do it for the rest of us. Furthermore, not only do they ship buggy drivers, but they frequently refuse to fix them.
Simply put, binary-only drivers are bad for Linux.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
*THACK*
It's not the same driver for all hardware (ie, not the same driver for video/audio/cd-rom/etc.), it's the same driver for each piece of hardware across differant opperating systems! (write one driver for your piece of hardware, have it work for all OS's supporting the standard)
Who said anything about Creative?
How will the UDI fix that problem?
The wheel is turning but the hamster is dead.
The wheel is turning, but the hamster is dead.
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.
And yet, if you look at the history involved here, which UNIX-like OS has the most drivers? Your argument has no basis in logic; if we are able to have more drivers for Linux right now than any of the other commercial UNIX systems, then it is they who should be adopting the Linux driver system, not the other way around.
The UDI sounds like a good idea, but what people seem to be missing is that with the source code, a driver is a simple thing to implement. The underlying feeling about the UDI is that binary drivers are going to be a necessity -- and in that case it will not help anyway because new architectures and operating systems will break it. (not to mention that the core open source developers for freeUNIX systems will not use them anyway). We have seen this in action several times -- look at the Riva TNT and more recently the ATI TV card (although I still can't figure out why anyone would want a TV on their computer). In both cases, they allowed open drivers to be implemented for their cards. ESR makes some very good points on this subject -- the turn-around for hardware secrets is measured in months and so companies will open up their source after that time anyway; see www.opensource.org for more information.
The wheel is turning but the hamster is dead.
The wheel is turning, but the hamster is dead.
Uhm - you sure about this - I'm
willing to bet that Adaptec got their
driver QUALIFIED before W95 was released
to the public, but they wrote it
themselves. How do I know - well - uhm...
hehehe.
Have you compiled your kernel today??
Well - the GPL is viral in nature, i.e. if
you are creating a derived work from GPL
source, or even linking to GPL'd code, then
you probably have to release the code in
source form as well to comply with the GPL
or you aren't allowed to link it. Now there
is a VERY specific permission granted by Linus
for binary modules. But from my reading of the
Kernel traffic report - he's having second
thoughts!
Have you compiled your kernel today??
the last time this appeared on slashdot the biggest complaint was that it only worked on intel boxes. thus, it is not a solution for linux, since you'd leave out the ppc, sparc, alpha, c64, etc. if this is still true, then it must die or evolve into cross-platorm.
This is good. I just hope those lazy vendors (most of them) get their thumbs out of their asses and hop on this. A single driver for multiple UNIX's, how hard can things get?
/ i got real good bongo drums
By the time you succesfully reverse engineer a VLSI design based on its programming instructions NVida will have long since come out with something newer and better. In most cases it would be simpler to just design your own chip. Even if you duplicate / emulate NVida's instruction set, that can only entrench NVida as a dominant standard and give them the initiative.
Finally, open specs is definetely a big marketing point, especially if they want to succeed in the emerging Linux market. I will stick to my trusty Matrox and 3dfx cards since both are well supported in Linux and have open specs. It would be in NVida's interest to release the specs. It will sell more cards.
Although there is truth to this statement, it is being a bit optimistic. I remember when Java was going to be the language that all applications are written in because of its portability. "write once, run everywhere"
The problem is that there are many different java virtual machines with lots of unique bugs and most of them are slow. The same (although to a lesser extent, probably) will happen with UDI. After we play with the first few UDI drivers, we'll start to find out that companies only test their driver with a few operating systems and that because of timing issues or bugs, the driver will probably only work well under the 2-3 operating systems it was tested on. Only slightly better than the current situation.
Anyone that has spent some time on software projects knows just how funny it is when people say things like "well, this works with X so it should work with Y". I've only been a programmer (professionally) for about a year and I've learned this lesson 10 times over.
The thing I worry about the most is the way UDI could tie kernel hackers' hands. There are occasionally changes that need to be made to the drivers in order to support new features. This might not be possible if they have to support UDI drivers.
For example, one of the major recent changes to the kernel architecture was the migration from v2.0/early 2.1 with a single kernel lock to late 2.1/2.2 with multiple locks, to handle SMP better. I'm not a kernel internals expert by any stretch, but it seems like one of the major changes required for this was to make all the SCSI and Ethernet drivers aware of the various differnt types of kernel lock.
How many times have kernel architecture changes occurred that required thorough driver updates? How difficult would this become with accumulated binary cruft that nobody would be willing to change just because one OS wants to rearchitect its kernel?
It's not a question of abstract notions of Stallmanesque software liberty. It's a question of compromising the plain flexibility and usefulness that made Linux great in the first place.
-Graham
In a past life I worked for a consortium that provided binary compatibility testing across vendors machines that used the Motorola 88k processor. If they passed our tests the idea was that their code was "guaranteed" to run on all member vendors platforms that we had also certified. That meant that even if the vendor did their port on platform A they had to support it on platform B, no excuses!
Will the card vendors who produce UDI drivers be willing to guarantee they will work on all UDI platforms?
Hardware maker should be encouraged to release hardware specifications! This is going in the opposite direction from what we want.
I agree. While it is nice to have a standard, and it would be double nice to be able to have the newest wizbang hardware run under Linux, I think this is just going to encourage vendors to keep their specs secret.
And that is a Bad Thing.
Stand up and say NO to UDI in the Linux Kernel. If it is put in as a patch, let us not compile it in!
This sig is false.
But kernel drivers do not use the system call interface. They operate directly on kernel internals. Why are they not derived works, as claimed by other posters? Did Linus exempt them? I don't see an exemption in the license.
The GPL claims that derived work essentially must fall under its umbrella. The UDI API implementation will have an incenstuous relationship with the kernel, and couldn't be considered anything but derived. The UDI drivers distributed by device manufacturers will then interface with the exposed UDI interface. Does the GPL consider the UDI drivers, which may have been developed on a different implementation of UDI, to be derived works because they interface with the Linux kernel? Should this be another case of fair use?
UDI should be a secondary device interface, if added to the kernel. The Linux kernel device interface is the right way. Not from a religous standpoint, but because it has evolved through the hands of many competent contributers that wanted to design the ultimate solution; one that satisfied the requirements of speed, stability, simplicity, extendibility, etc. In other words, to maintain the integrity of the kernel. The UDI interface on top of Linux is a dilution. A perversion of something that is better.
I think UDI should be prohibited from the official kernel if UDI drivers can be distributed in binary form. Linux is synonymous with stability and robustness. In part because it benefits from peer review. Binary modules are unknowns, with access to enough of the kernel to debilitate it! We should apply a general rule: anything which runs within the kernel's address space should be open source. Open source device drivers are worth the fight, especially so that they can be changed to conform to the Linux device driver interface.
Incorrect. /dev/3dfx is open source.
There is nothing "interesting" from the 3dfx interface in /dev/3dfx. It just does some programmed I/O and memory mapping. So releasing it open source wasn't a problem.
I didn't break that ground, but it will happen soon I suspect.
- |Daryll
The point of the UDI as I understand it is to make drivers work on multiple OSes, not to make them work for Linux users. As far as I know, Linux is the only OS that uses the Linux kernel.
-lx
Disclaimer: IANAL
You could release a UDI driver under GPL, but Windows or any other closed-source system could still use them, as long as their OS-side UDI support wasn't based on GPL code. If Microsoft implements UDI support for Windows based on the (public domain) UDI specification, that code is a derived work of that specification, not of the driver which is also derived from the same UDI specs.
Of course, if there is a special driver-specific interface that only exists on the GPL-covered driver, then an application or OS which uses those features would probably then be considered a derived work of the driver. Otherwise, you can't keep proprietary vendors from using your UDI drivers just by licensing them under the GPL. (They'd still have to distribute the source code of the UDI driver itself, of course, to comply with the GPL.)
Don't think a boycott of UDI would matter either; if a proprietary vendor supports UDI and wants to use your GPL-covered driver, they can always port your driver to the UDI interface. They'll have to release the sources to those changes, but they'd be free to use it for a proprietary system after that.
The genie is out of the bottle on this one. But I think it's a Good Thing (tm). After all, UDI driver compatibility is only guaranteed at the source level; some similar platforms may have binary compatibility, but Solaris/SPARC and Linux/x86 certainly won't be binary-compatible. This might actually encourage some vendors to release source to their UDI drivers for widest compatibility, when they might not have been inclined to release source code otherwise.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
For example, one of the major recent changes to the kernel architecture was the migration from v2.0/early 2.1 with a single kernel lock to late 2.1/2.2 with multiple locks, to handle SMP better. I'm not a kernel internals expert by any stretch, but it seems like one of the major changes required for this was to make all the SCSI and Ethernet drivers aware of the various different types of kernel lock.
This could be viewed as a failing in the Linux driver interface. Ideally, the driver writer should not have to be concerned with changes to the kernel. Of course, this isn't so easy in practice. From a quick look at the HTML overview on the UDI website, one of the things that jumped out at me is that the UDI specification seems to shield driver writers from many details of OS implementation.
Take this change in kernel locking for SMP, for example. The UDI spec says that drivers don't deal with synchronization issues AT ALL. It uses a non-blocking execution model. The OS support for the UDI environment would have to deal with the change in kernel locking, but all UDI drivers would have continued to work without modification, at least in theory. Isn't this a valuable benefit for changing driver architectures?
I haven't read the actual UDI spec yet, but from the overview, it seems to be very well designed and thought out. It leaves a LOT of flexibility in the OS implementation, although it also appears to place a lot of the responsibility on the OS support code more than the driver. This seems reasonable to me; that code only has to be written once for each OS; if multitudes of drivers can be simplified and made more stable by putting more work into the OS support, isn't it prudent to do so?
One more thing: UDI drivers could be implemented in user space or kernel space; perhaps the Linux UDI implementation could be done in such a way as to provide protection of the system from a faulty driver? If a particular hardware vendor's driver keeps crashing, that vendor will get the blame, not Linux itself... Instead, Linux would get more credit than ever if the rest of the system can survive driver crashes. (Potentially, the kernel could even reinitialize crashed drivers automatically.)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Disclaimer: IANAL (I Am Not A Lawyer.)
It is an inaccurate generalization to claim that all binary-only modules violate the GPL. Yes, the Linux kernel is licensed under the GPL. Yes, the implemention of OS support for UDI under Linux would be covered by the GPL. However, this does not mean that the GPL necessarily applies to UDI drivers.
Why is this? How can a binary driver be loaded into the GPL'd Linux kernel without violating the GPL? Simple. UDI drivers are not inherently derived from GPL-covered code. If the same UDI interface existed only under Linux, then implementing a driver to that interface would constitute a derived work, and subject that driver to the GPL's constraints.
Since UDI was developed independently and is being placed in the public domain, drivers written to the UDI interface are not subject to the GPL, even if you link them into the GPL-covered Linux kernel.
Legally, the key point is whether or not it constitutes a "derived work", not whether or not they are used together. The OS-side Linux UDI implementation would be a derived work of the UDI specification, but the UDI specification is not a derived work of Linux. A given UDI driver would be a derived work of the UDI specification as well, but not a derived work of Linux. Therefore, a binary-only UDI module running under Linux would not violate the GPL, even if you link that module statically into the kernel...
That said, if a particular UDI driver started out as a Linux kernel driver, then it would already be a derived work of Linux, therefore covered under the GPL. Of course, the author(s) could presumably change the license if the UDI version of the driver is no longer derived from the GPL-covered code. Third parties, however, could not relicense this way, even if the UDI version no longer contains any derived code.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Who said Microsoft would support UDI? They've got their own driver model.
Who says Microsoft needs to? Even if Microsoft refuses to support UDI, couldn't any third party use Microsoft's interface and create a driver that provides MicrosoftUDI translations to run UDI drivers under? This could be written once and used with many UDI drivers. (Obviously, direct OS support is always better, but it's not the only option here.)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Some pretty good video cards actually don't have OpenGL drivers (often, if they claim to support OpenGL they actually only support some subset that's good enough for games but not much else).
In addition to the practical utility, it also shows that given the compute power of modern hardware, Microsoft's attempts to control APIs are getting more and more futile. Microsoft may have wanted to see OpenGL die, but people are going to wrap OpenGL around Direct3D anyway.
This is happening in other areas with Windows anyway. A lot of code is written to C++ and POSIX APIs rather than Microsoft's native APIs. And people have wrapped OpenGL around the Direct3D interface (with at least some success). And in all those cases, the non-Microsoft APIs are a lot nicer to use.
If there's a downside, it's not immediately apparent.
Implicitly portable drivers can only be good for the consumer. If hardware manufacturers choose (correctly) to free their drivers then the consumer's realm of bootable OSes is broadened.
One of the excellent points made in "In The Beginning Was The Command Line" was that hardware manufactures will always write drivers for the Windows family of products. Microsoft doesn't have to lift a finger. Linux relies on volunteers to reverse engineer new devices. Be must hire people to do write drivers in-house.
How would the landscape change if every "alternative" OS was on equal footing with Microsoft in this respect?
--
Showroom Dummies.
I disagree about the Linux device interface being clean and well documented.
This comment from netdevice.h (2.2.4) illustrates a problem with the network device interface:-
/*
* The DEVICE structure.
* Actually, this whole structure is a big mistake. It mixes I/O
* data with strictly "high-level" data, and it has to know about
* almost every data structure used in the INET module.
*
* FIXME: cleanup struct device such that network protocol info
* moves out.
*/
I have read the Linux Device Drivers book from OReilly which is a good start but it does not have any details about PCMCIA, CardBus and other newer hardware. It has only sketchy descriptions of functions and their return values and relies a lot on code examples which are readily available in the kernel source anyway.
Another problem I have with the Linux kernel interface is that it changes a lot between kernel versions.
There is nothing wrong with binary modules. Ok so it goes against the spirit of things but some hardware companies just will not release source code (mine included). With a single driver interface they only have to have one source tree and can compile the driver for all UNIXes. This I see as a benefit for Linux.
Linux will always have drivers for well documented hardware. It will never have drivers for propriety hardware unless the hardware vendor writes one. With a common driver interface this is much more likely.
From Tom
If a binary driver is unstable under Linux, then it will also be unstable under Solaris/x86, SCO, etc. If it works well on those platforms, then it will work well under Linux (assuming the UDI environment of Linux is stable, which I believe it will be, since it will be one of the reference platforms).
This is a Good Thing [tm] for Linux and Unix-like OSes in general.
Now, to the source code issue... It might be that, with the most widely used UDI implementation around, drivers for that environment might get opened up by the manufacturers. Don't count on it, but is there really any reason to not open up the source to a device driver for a platform like that? Once the standard is set, there will be no silly driver interface licensing issues with major Unix vendors (for whom the decent I/O peripheral companies will write drivers).
This could be a Very Good Thing [tm].
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
Umm... it already *does* that. How do you think you can stripe a SCSI disk and an IDE disk together? Simple, because to the kernel layer above the raw device drivers they look *the same*.
This would not slow anything down if the UDI environment were to exist side-by-side with the current Linux Driver Interface, rather than below it.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
I read an earlier version of the standard from fron to back and, while the draft was rough as hell, it seemed fairly complete and well-designed. A lot of it dovetails with the Linux Driver Interface. There were a couple problems with it that I could see, in that there wasn't enough possibility for dynamic configuration of drivers at a general level, and finer-grained configurability at instance levels, but all in all it seemed a good specification.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
Especially for things like video and sound drivers, you are correct. The problem with it is, there is no way to know if you have the whole specification.
With this specification, you do have the whole thing.
Windows' device model is, from what I've heard, way too foreign to be integrated.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
In that case, then, we have the interface to use in debugging and reverse-engineering the driver. It's a sensible interface, unlike the things I've heard about Windows drivers, and since it's a standard, there won't be any niggling little OS-specific hooks.
Even if the vendors don't release code, the job of supporting their hardware still becomes easier, and we can test the function of our open drivers against that UDI driver.
This is still a Good Thing.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
No, UDI is binary compatible across similar OSes on the same platform. SCO and Linux and Solaris could all use the same binary driver in a UDI environment.
Your point about the possibility of more open-source drivers resulting from this is a good one. Not because of the reduced engineering effort to produce a driver (that will simply increase the quality of the driver), but because there will be no proprietary information for each vendor needed in the driver. They will use a common interface, rather than a XYZOS interface, the publishing of which certainly has legal ramifications.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
Hmm... anyone want to start a new movement with a lot of press hype and industry buzz?
;-) movement make any headway in this arena?
I recently bought a Matrox G200-based card *based on their decision to open the programming specs*. I emailed them and told them so, too, and told them that if they opened the specs for the upcoming G400 (which looks to be very cool, BTW), I would upgrade all the systems within my grasp to that.
You have to vote with your pocket books, and don't forget to tell the vendors why you made the choice you made.
I wonder, though... could an "Open Specs" ([tm] [r] [c]
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
They, just like the Linsux kernel, are in "release mode" right now. They've got to stop discussing at some point and publish a standard. The one they have is relatively decent, and so with a bit more discussion, minor fixes, etc. it can be released.
Is this not logical, especially for a standards body?
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
I think this may be good for Linux, with UDI support, we'll probably get more vendors willing to supply drivers for Linux.
I think Nvidia has all the right in the world to keep their well-researched technology from getting into everyone's hands. They have to make money, you know. If they are forced to release the source code to their drivers, it would make it _extremely_ easy to reverse-engineer their technology.
If a company releases bad drivers, I think it will become quickly clear to people and they will jump up and down and boycott company Z until they get on the ball. It's a trade-off, for sure, but I want to play GL q3a in Linux!
Operating systems are not that simple, and interfaces designed by committee (like UDI) are rarely simple or robust (Not that I've actually looked at the UDI spec :-P ) Because something is stable under Solaris or SCO does NOT mean that it will be under Linux or *BSD. At least with open source drivers, the problem can be fixed by whoever is having problems.
> Once the standard is set, there will be no
> silly driver interface licensing issues with
> major Unix vendors (for whom the decent I/O
> peripheral companies will write drivers).
Unfortunately, this is not the reason that many companies site when defending closed-source drivers. Creative Labs and 3dfx are both excellent examples of this. Neither company is providing open source Linux drivers for some of their products because they will be "giving away their intellectual property." The main reason for keeping drivers closed source is to protect the hardware interface to the board, not to protect the driver I/O interface. Winmodems are another example.
Personally (except for the winmodem case), I don't understand this argument, the IP to protect should be in the design of the chips themselves, not in the interface. Maybe both Creative Labs and 3dfx have algorithms in their drivers which they want to protect (Which definatly is the case for Winmodems).
Just because UDI is a GoodThing for proprietary UN*X, that doesn't mean it's a good thing for open source UN*X. Don't confuse a commercial GoodThing (tm) with an Open Source GoodThing (tm)
If the Linux community embraced closed-source drivers, it would definatly be counter-productive because we would lose the part of Linux that has brought it to where it is today; it's free origins.
Is there an implimentation of the UDI being developed for Linux? It would almost have to be a kernel-space project and I don't remember seeing anything about it on the list.
/. finds me to be 20% Troll, 80% Funny
It's only when your changes involve the kernel itself that GPL virulence comes into play.
The strength of the Linux kernel, which includes its device support, is its freed, opensource nature. Binary-only modules hurt that.
That's also its weakness. I was forced to install completely different SCSI hardware because Western Digital no longer supports the 719x and refuses to distribute chipset-level information on it, claiming that their SCSI product line was sold to Adaptec (who disavow anything to do with the 719x, calling it "obsolete." Why buy products just to discontinue them?)
I'm perfectly aware of the undergroundish project to write drivers for the WD719x, but they are:
Here's where I'd take a binary-only driver over no driver at all.
I should also add that support for SCO is our bottom zero priority.
Is your bottom priority. People who run SCO UNIX might think differently. Although I think they all went away in the 80s, didn't they? People don't seriously run SCO any more, do they? No, really?
solution : Richard Gooch's brilliant work : devfs.
/dev | wc" yields 52 entries (that makes 7 lines x 80 characters, pretty manageable, isn't it ?), while "ls /dev/**/* | wc" gives 422 devices total (and I'm still running with the glibc2.0 compatibility symlinks, together with a few custom links I had to do to support legacy stuff [call this laziness]). Yet almost all the device nodes there are functional and mean there's actually a device behind.
Really cool (I wish Linus said why he didn't include it in the official 2.2 tree, though he said at one point (circa 2.1.105 ?) that he was considering it). FWIW, I'd be quite unsurprised to see some devfs-based distributions out there soon (I'm speculating the Bero/Mandrake folks would be the kind of people to attempt this first).
On my (work) machine, "ls
(now, what does this have with major/minor ? Easy, the devfs support routines either use the legacy magic numbers, if so requested by the drivers, or can assign new ones on the fly, as available. Either way, major/minor is now an (almost) irrelevant feature, only the device node counts).
(Oh, yes, Solaris' been doing something quite similar for some time, though not that bold and confident, some other OSes may do too, but I'm quite an ignorant).
-- Cyrille
Use xpdf. You may need to get it from Europe for
the crypto add on. Adobe made PDF basically an open protocol like postscript but one they already had a good lead on. Nice sensible way to do things
People may even release a GPL'd UDI for the Linux kernel. I don't think anyone should expect it to make the main kernel tree. Like streams its one of those dumb ideas that doesn't merit mainstream kernel support.
Ya'll are gonna have to help me out here, 'cause I don't understand several of the arguments against the UDI?
First, if the UDI is an interface specification, and the Linux kernal is modified to accept drivers written to that interface, why would the kernel EVER need to be modified in order to work with a binary driver? Isn't it the point of the UDI to remove the need to modify the kernel for driver compatibility?
Second, if Matrox as a company woke up one morning and decided to open their video drivers under the GPL, what effect would that have on OS/2 or Windblows? Would IBM or Micros~1 feel compelled to open their source?
Put these two together, and I don't see how making the Linux kernel compliant with the UDI (and thereby encouraging binary only drivers) could possibly be bad for Linux. VendorA will think it in their best interest to keep their buggy drivers closed, while VendorB will open theirs up to peer review. Guess who'll end up with the better driver support/more stable product. As VendorB gets more and more support, people ignore VendorA, until eventually VendorA catches a clue.
However, in the interim, I can't see how VendorA hiding his source can hurt the GPL as long as the interface to the kernel is through PUBLISHED interfaces. If you say the drivers have to be open, then there isn't any program that would be able to run under Linux without being GPLed (unless of course, the program didn't use the keyboard, screen, disk drive, or memory which are all managed by the kernel 8*).
I find this argument nearly as ridiculous as those silly executives stating publicly that Linux needs standards because it is going mainstream and and that the Linux community is just going to have to get used to it. I can peacefully tell them all to go screw themselves. This community doesn't have to accept anything from the corporate elite. If you like our work use it, if you don't, that's fine, too. But Linux got where it is because some hackers wanted to play. Those hackers will continue to play wherever they like. We'll release a new version every day or once a year, corporate IT be damned.
If some corporate types want to publish an interface spec, GREAT!! If it's good we'll use it, if it's not we'll ignore it. If we modify the kernel to take advantage of some binary drivers that will open up another choice. If the binary drivers are good they'll get used, if not they'll be ignored.
So, since we are the ones in control (because we don't NEED anything from IBM, SUN, SCO, etc), how can compliance with a published spec be detrimental to the GPL, the Linux community, or Open Source?
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
Unixware has already had one new standard interface for device drivers, the portable driver interface (back when it was AT&T/USL). This seemed to be stillborn, perhaps due to the sale of Unix to Novell. Before that they had DDI/DKI in System V, which is still documented as the standard interface for Solaris. Maybe this one will live as long as the PDI did.
Changes aren't permanent, but change is.
Perhaps. But at least there'd be a working driver to tide people over until someone gets a GPL'd implementation written.
Hm. I wonder if a UDI 'sniffer' would be possible.
The ambitions are: wake up, breathe, keep breathing.
UDI is truely a good thing. Some of you have pointed out Linux has a good driver model. That might be the case but this is a set of APIs that allow the same driver to be run on any OS that support it. Well, then why not port the lLinux code to other OSs? Because there are flaws in Linux like any other OS.
I also seem to be hearing that vendors will release buggy binary drivers. Why? the drivers are the same for every OS. If it works buggy on Solaris it will Work buggy on Tu64 and Linux.
Can you explain why the distribution of binary driver images is a bad thing? As long as they run on all platforms, I dont see the problem.
Actually, with NT5 (WIN2000) NT will use WDM (Windows Drivers Module or something like that) just like win98. So one set of drivers will be good for windows platforms, while another set of drivers will be good for the rest of us.
You have to understand that corporations think RMS is a nut (I don't, but they do). OSI is much more corporation-friendly. We insist on the same freedoms as free software (there will be an APSL 1.1 -- let he who is without sin cast the first stone), so we're hacker-friendly too.
-russ
Don't piss off The Angry Economist
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...