UDI spec 0.90 available for review 130
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.
Parallel Port (Score:1)
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.
UDI is not a GoodThing (Score:1)
It's not gonna happen (Score:1)
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.
Uhh no (Score:1)
not a solution (Score:1)
UDI is cross platform.
UDI is not a GoodThing (Score:1)
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.
We already have a quite nice UDI, thankyou. (Score:1)
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
Open Source == Free Software (Score:1)
It may be automatic. (Score:1)
I don't like it, it's Malda's decision to make...
We already have a quite nice UDI, thankyou. (Score:1)
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?
Great! Let's have a UDI adapter for Windows! (Score:1)
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
It's not gonna happen (Score:1)
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
GPL/UDI licensing issues... (Score:1)
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)
Is this really valid? (Score:1)
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
Conspicuously Absent (Score:1)
How to pick major and minor #s for new driver? (Score:1)
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.
We already have a quite nice UDI, thankyou. (Score:1)
Good and bad at the same time (Score:1)
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.
... but drivers *will* be buggy (Score:1)
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.
How? (Score:1)
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)
Uhh no (Score:1)
Who said anything about Creative?
How will the UDI fix that problem?
The wheel is turning but the hamster is dead.
We already have a quite nice UDI, thankyou. (Score:1)
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.
Good for EVERYONE (except mabe Microsoft) (Score:1)
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.
Irrelevant if you want Linux to be widely accepted (Score:1)
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!
not a solution (Score:1)
Great! (Score:1)
Reverse Engineering? (Score:1)
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.
UDI is Great (Score:1)
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.
How does UDI handle future architecture changes? (Score:1)
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
UDI may not be supported on all platforms (Score:1)
Will the card vendors who produce UDI drivers be willing to guarantee they will work on all UDI platforms?
Encouraging hardware vendors (Score:1)
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!
why are kernel drivers exempt from GPL? (Score:1)
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.
The linux kernel license needs clarification (Score:1)
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
We already have a quite nice UDI, thankyou. (Score:1)
-lx
GPL your UDI drivers, but Windows could use them. (Score:1)
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.
How does UDI handle future architecture changes? (Score:1)
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.)
Binary-only UDI drivers would NOT violate the GPL. (Score:1)
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.
Windows UDI could be third-party. (Score:1)
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.)
Great! Let's have a UDI adapter for Windows! (Score:1)
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.
Great! Let's have a UDI adapter for Windows! (Score:1)
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.
Good for EVERYONE (except mabe Microsoft) (Score:1)
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" [io.com] 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?
Good for EVERYONE (even Microsoft) (Score:1)
Showroom Dummies.
We already have a quite nice UDI, thankyou. (Score:1)
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
UDI is not a GoodThing (Score:1)
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
Another indirection... (Score:1)
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
Closed-source drivers (Score:1)
--Corey
It's not gonna happen (Score:1)
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
UDI is not a GoodThing (Score:1)
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
How? (Score:1)
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
Open Specs (Score:1)
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
Gah! PDF files for documentation? (Score:1)
Is this not logical, especially for a standards body?
--Corey
Good for Linux (Score:1)
Linux needs all the help it can get (Score:1)
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!
Closed-source drivers (Score:1)
> 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).
UDI is not a GoodThing (Score:1)
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.
UDI Spec for Linux? (Score:1)
Binary-only modules (Score:1)
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?
How to pick major and minor #s for new driver? (Score:1)
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
pdf? (Score:1)
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
UDI and the kernel tree (Score:1)
Whence the paranoia? (Score:1)
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?
Anyone Remember PDI? (Score:1)
Good and bad at the same time (Score:1)
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.
UDI is Great (Score:1)
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.
We already have a quite nice UDI, thankyou. (Score:1)
Good for EVERYONE (BUT Microsoft) (Score:1)
Open Source == Free Software (Score:1)
-russ
Common Architectural Interface. (Score:2)
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
How? (Score:2)
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.
UDI Spec for Linux? (Score:2)
that they would be working on a Linux UDI implementation. Intel seems to be very supportive
of UDI.
Good and bad at the same time (Score:2)
Make sure to GPL your UDI device drivers, so that they don't show up on closed-source platforms.
Bruce
URL of the previous discussion (Score:2)
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.
The linux kernel license needs clarification (Score:2)
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."
Dilution of the GPL. (Score:2)
Last time I checked.. (Score:2)
"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.
Good for EVERYONE (except mabe Microsoft) (Score:2)
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.
--
Good for EVERYONE (even Microsoft) (Score:2)
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.
--
Last time I checked.. (Score:2)
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.)
--
Articles scoring a bit high. (Score:2)
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.
Irrelevant if you want Linux to be widely accepted (Score:2)
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.
UDI is not a GoodThing (Score:2)
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.
Parallel Port (Score:3)
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.
--
We already have a quite nice UDI, thankyou. (Score:3)
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.
--
UDI is not a GoodThing (Score:3)
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.
--
Good for EVERYONE (except mabe Microsoft) (Score:3)
OK, I stand corrected. Although, it does say Copyright Microsoft all over it, with no Adaptech copyright.
--
Is this really valid? (Score:3)
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.
We already have a quite nice UDI, thankyou. (Score:3)
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.
We already have a quite nice UDI, thankyou. (Score:3)
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.
GPL your UDI device drivers... (Score:3)
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
We already have a quite nice UDI, thankyou. (Score:4)
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.
Dilution of the GPL. (Score:4)
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.
We already have a quite nice UDI, thankyou. (Score:4)
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.
We already have a quite nice UDI, thankyou. (Score:4)
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.
Plusses and Minuses evident (Score:4)
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.