Comments on: The Uniform Driver Interface—why wasn’t it adopted? http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/ My writing on life, computers, and technology Sat, 26 Feb 2011 18:10:29 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Michael Trausch http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-424 Michael Trausch Sun, 07 Mar 2010 10:31:05 +0000 http://mike.trausch.us/blog/?p=592#comment-424 @lefty.crupps: Yes, I am pretty well aware of the Linux kernel's policy and why they want to have drivers in-tree. Though, that brings up an interesting point: a specification could even be as loose as an ABI/API spec based upon, say, the Linux kernel at a given point in time. Though, that would also probably very heavily influence other operating systems that implement the interface. There are, as oiaohm mentioned, other portable userspace driver implementations for various types of drivers. I'm going to have to look into them and perhaps write up on what I find next. @lefty.crupps: Yes, I am pretty well aware of the Linux kernel’s policy and why they want to have drivers in-tree. Though, that brings up an interesting point: a specification could even be as loose as an ABI/API spec based upon, say, the Linux kernel at a given point in time. Though, that would also probably very heavily influence other operating systems that implement the interface.

There are, as oiaohm mentioned, other portable userspace driver implementations for various types of drivers. I’m going to have to look into them and perhaps write up on what I find next.

]]> By: Michael Trausch http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-423 Michael Trausch Sun, 07 Mar 2010 10:24:12 +0000 http://mike.trausch.us/blog/?p=592#comment-423 @Jonathan: I could not have said it better myself. There is a lot that we can learn from just stopping and listening to common sense. Life's too short to stand at the end of a spectrum and scream until we keel over from high blood pressure or something like that. @Jonathan: I could not have said it better myself. There is a lot that we can learn from just stopping and listening to common sense. Life’s too short to stand at the end of a spectrum and scream until we keel over from high blood pressure or something like that.

]]> By: Michael Trausch http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-422 Michael Trausch Sun, 07 Mar 2010 10:22:37 +0000 http://mike.trausch.us/blog/?p=592#comment-422 @oiaohm: I was aware of FUSE. I didn't know about the existence of BUSE and CUSE, though. So, I suppose between (F|B|C)USE and NDIS, we cover /most/ types of drivers. Are there ports of (B|C)USE to Windows and OS X? I know that there is a FUSE for Mac, and I think (if memory serves) that there is one for Windows as well. Thanks for your comments—it would seem that there was more out there than I was aware of. Of course, userspace drivers come at a cost on operating systems where they are not the norm (e.g., µkernel systems where they take into account that that is their primary [indeed, <em>only</em>] type of driver and make things very efficient for going back and forth). It's still nice that there is the ability for them. I will take a look into those things. @oiaohm: I was aware of FUSE. I didn’t know about the existence of BUSE and CUSE, though. So, I suppose between (F|B|C)USE and NDIS, we cover /most/ types of drivers.

Are there ports of (B|C)USE to Windows and OS X? I know that there is a FUSE for Mac, and I think (if memory serves) that there is one for Windows as well.

Thanks for your comments—it would seem that there was more out there than I was aware of. Of course, userspace drivers come at a cost on operating systems where they are not the norm (e.g., µkernel systems where they take into account that that is their primary [indeed, only] type of driver and make things very efficient for going back and forth). It’s still nice that there is the ability for them. I will take a look into those things.

]]> By: Yfrwlf http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-421 Yfrwlf Sat, 06 Mar 2010 12:50:54 +0000 http://mike.trausch.us/blog/?p=592#comment-421 Agreed. Standards = freedom. Why it was never done and why there isn't a community push to implement it? That's beyond me. Even if the Linux distros had some silly reason for not wanting it, users should still want it. Agreed. Standards = freedom. Why it was never done and why there isn’t a community push to implement it? That’s beyond me. Even if the Linux distros had some silly reason for not wanting it, users should still want it.

]]> By: oiaohm http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-420 oiaohm Sat, 06 Mar 2010 01:12:49 +0000 http://mike.trausch.us/blog/?p=592#comment-420 I really missed one. cuse covers all char devices from user space. buse covers all block devices from user space. fuse covers all filesystem from user space. Only things not covered by this is network cards and devices you cannot directly talk to from userspace. cuse and buse interfaces follow posix so any posix OS can have them implemented. Even better freebsd follow the posix agreement of 2001 of supporting applications built using linux syscalls since those are stable. Basically there is your cross platform neutral driver. Built using only Linux syscalls running in user space and interface by cuse or buse or fuse to setup their block devices. Covers all of the posix world bar Mac OS X. The idea that something equal to UDI does not exist today is wrong. All USB and Firewire drivers could be done using cuse and buse other than printers and network devices. By the way userspace printer drivers are also stable across lots of platforms so not being able to do them in cuse and buse is not a issue. libusb makes the USB bit simple. Firewire has the same interface on all posix os's. Makes life a lot simpler. PCI and PCI-e some are supported issue is interp handling but that is improving. Motherboard chipset for memory control basically always kernel space and out question to handle any other way. UIO support in Linux that is not across other POSIX OS's at this time can do network card and all the PCI and PCI-e drivers that cuse and buse cannot do. Basically UDI died. New stuff grew up in it place. Basically stop spreeding the myth that cross platform driver tech does not exist. It does hardware makers choose not to use it. I really missed one.

cuse covers all char devices from user space.
buse covers all block devices from user space.
fuse covers all filesystem from user space.

Only things not covered by this is network cards and devices you cannot directly talk to from userspace.

cuse and buse interfaces follow posix so any posix OS can have them implemented. Even better freebsd follow the posix agreement of 2001 of supporting applications built using linux syscalls since those are stable.

Basically there is your cross platform neutral driver. Built using only Linux syscalls running in user space and interface by cuse or buse or fuse to setup their block devices. Covers all of the posix world bar Mac OS X.

The idea that something equal to UDI does not exist today is wrong.

All USB and Firewire drivers could be done using cuse and buse other than printers and network devices. By the way userspace printer drivers are also stable across lots of platforms so not being able to do them in cuse and buse is not a issue. libusb makes the USB bit simple. Firewire has the same interface on all posix os’s. Makes life a lot simpler.

PCI and PCI-e some are supported issue is interp handling but that is improving. Motherboard chipset for memory control basically always kernel space and out question to handle any other way.

UIO support in Linux that is not across other POSIX OS’s at this time can do network card and all the PCI and PCI-e drivers that cuse and buse cannot do.

Basically UDI died. New stuff grew up in it place. Basically stop spreeding the myth that cross platform driver tech does not exist. It does hardware makers choose not to use it.

]]> By: oiaohm http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-419 oiaohm Sat, 06 Mar 2010 00:41:41 +0000 http://mike.trausch.us/blog/?p=592#comment-419 Linux and freebsd both had UDI support in 2001. SCO added it in 2003. UDI was even mainline Linux kernel for a while. Simple fact FSF had nothing todo with UDI dieing. No drivers came. I repeat no drivers came. If hardware makers were not going to use it there was little point keeping it around. Linux kernel and Freebsd kernel disregard FSF in regard to firmware. This is where you have a problem say FSF has anything todo with the driver matter. Lot of hardware makers have gone the path of loadable firmware with open spec interfaces. Reason firmware allows them to keep their secrets. Open spec interfaces allow better driver optimization without having to use an extra wrapper like UDI. Also there are advantages to this. Firmware screws up mostly it contained to the hardware its on. So complete OS does not die. Basically Linux kernel developers have a issue with closed source binaries in kernel space where if they screw up can completely stuff the secuirty of the OS. NVidia is to blame a lot of this. Yes closed source driver makers have avoided using provided interfaces and gone for Linux Kernel internal interfaces because they are faster. Then tried demanding they stay stable. Basically go over the http://udi.certek.com/f-participants.html list and see if you can find 1 UDI driver. Yep there are none. Then Nvidia and other closed source drivers for Linux and Freebsd not once did they release a UDI driver. These days there is a new common driver systems. cuse and fuse shared between FreeBSD and Linux and others. Advantage it don't need kernel space. So secuirty of OS can be maintained. Since it closer to posix OS's it works better. There is also UIO in the Linux kernel that is used in the embed space. So basically between fireware, cuse, fuse and uio there are stable api's to build closed source drivers on Linux. Yet where are the drivers. "What would the world be like if we could write a device driver for Linux, and be able to use it on FreeBSD without modification?" Were have you been it already happens. Sorry 5 years too late to the party. Linux and freebsd both had UDI support in 2001. SCO added it in 2003. UDI was even mainline Linux kernel for a while.

Simple fact FSF had nothing todo with UDI dieing. No drivers came. I repeat no drivers came. If hardware makers were not going to use it there was little point keeping it around.

Linux kernel and Freebsd kernel disregard FSF in regard to firmware. This is where you have a problem say FSF has anything todo with the driver matter. Lot of hardware makers have gone the path of loadable firmware with open spec interfaces.

Reason firmware allows them to keep their secrets. Open spec interfaces allow better driver optimization without having to use an extra wrapper like UDI.

Also there are advantages to this. Firmware screws up mostly it contained to the hardware its on. So complete OS does not die.

Basically Linux kernel developers have a issue with closed source binaries in kernel space where if they screw up can completely stuff the secuirty of the OS. NVidia is to blame a lot of this.

Yes closed source driver makers have avoided using provided interfaces and gone for Linux Kernel internal interfaces because they are faster. Then tried demanding they stay stable.

Basically go over the http://udi.certek.com/f-participants.html list and see if you can find 1 UDI driver. Yep there are none. Then Nvidia and other closed source drivers for Linux and Freebsd not once did they release a UDI driver.

These days there is a new common driver systems. cuse and fuse shared between FreeBSD and Linux and others. Advantage it don’t need kernel space. So secuirty of OS can be maintained. Since it closer to posix OS’s it works better. There is also UIO in the Linux kernel that is used in the embed space.

So basically between fireware, cuse, fuse and uio there are stable api’s to build closed source drivers on Linux. Yet where are the drivers.

“What would the world be like if we could write a device driver for Linux, and be able to use it on FreeBSD without modification?” Were have you been it already happens. Sorry 5 years too late to the party.

]]> By: Math http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-418 Math Fri, 05 Mar 2010 23:42:37 +0000 http://mike.trausch.us/blog/?p=592#comment-418 Because drivers by standard are written mainly for Windows and Microsoft do not other OS to work nicely. Because drivers by standard are written mainly for Windows and Microsoft do not other OS to work nicely.

]]> By: Links 5/3/2010: Elive Stable 2.0 Topaz, Canonical CEO Speaks | Boycott Novell http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-417 Links 5/3/2010: Elive Stable 2.0 Topaz, Canonical CEO Speaks | Boycott Novell Fri, 05 Mar 2010 22:36:30 +0000 http://mike.trausch.us/blog/?p=592#comment-417 [...] The Uniform Driver Interface—why wasn’t it adopted? Imagine, for example, if drivers for graphics cards, TV tuner cards, video and audio encoding/decoding cards, modems, storage chipsets, motherboard chipsets, USB chipsets, IEEE-1394 chipsets, graphics tablet devices, touch screens, debugging interfaces, network devices, and so forth were all written to a common specification, it would reduce the amount of code which needed testing. It would increase user choice in both hardware and operating systems—something which I still hold is quite likely the most valuable freedom we have. It would increase reliability, since the users of Windows, OS X, Linux, the various BSD systems, and other, not-so-mainstream operating systems would be able to run the same driver code and collectively supply debugging information and perform testing in a multitude of environments. It would increase security, because then common code that is well-known could be used on all platforms and not just the one it was written for. It would do for device drivers what POSIX has done for user-mode application software. I do not believe that I could be convinced that this would be anything other than a good thing. [...] [...] The Uniform Driver Interface—why wasn’t it adopted? Imagine, for example, if drivers for graphics cards, TV tuner cards, video and audio encoding/decoding cards, modems, storage chipsets, motherboard chipsets, USB chipsets, IEEE-1394 chipsets, graphics tablet devices, touch screens, debugging interfaces, network devices, and so forth were all written to a common specification, it would reduce the amount of code which needed testing. It would increase user choice in both hardware and operating systems—something which I still hold is quite likely the most valuable freedom we have. It would increase reliability, since the users of Windows, OS X, Linux, the various BSD systems, and other, not-so-mainstream operating systems would be able to run the same driver code and collectively supply debugging information and perform testing in a multitude of environments. It would increase security, because then common code that is well-known could be used on all platforms and not just the one it was written for. It would do for device drivers what POSIX has done for user-mode application software. I do not believe that I could be convinced that this would be anything other than a good thing. [...]

]]> By: Stuart Norman http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-416 Stuart Norman Fri, 05 Mar 2010 21:22:41 +0000 http://mike.trausch.us/blog/?p=592#comment-416 Even better would be a Universal Driver Interface layer in every OS, but the driver would be in a rom chip in the hardware. No need to download or acquire a driver in any way. The driver would just report the function to the UDI and everything would work. And it wouldn't matter whether the driver code was proprietary or ope source. Even better would be a Universal Driver Interface layer in every OS, but the driver would be in a rom chip in the hardware. No need to download or acquire a driver in any way. The driver would just report the function to the UDI and everything would work. And it wouldn’t matter whether the driver code was proprietary or ope source.

]]> By: Jonathan http://mike.trausch.us/blog/2010/03/03/the-uniform-driver-interface%e2%80%94why-wasnt-it-adopted/comment-page-1/#comment-415 Jonathan Fri, 05 Mar 2010 16:13:32 +0000 http://mike.trausch.us/blog/?p=592#comment-415 I had no idea that such a project had ever been proposed. As you lay it out, the choice between a common UDI and a series of proprietary drivers seems blatantly obvious. Further, you're right in pointing out that the FSF does occasionally shoot itself in the foot by demanding entirely free software all the time, even when to use such would be to disadvantage the end user. As developers, we need to remember that it is the end user who we serve, and that no amount of hand waving about morals and principles will excuse software that performs poorly on the user's system. I had no idea that such a project had ever been proposed. As you lay it out, the choice between a common UDI and a series of proprietary drivers seems blatantly obvious. Further, you’re right in pointing out that the FSF does occasionally shoot itself in the foot by demanding entirely free software all the time, even when to use such would be to disadvantage the end user. As developers, we need to remember that it is the end user who we serve, and that no amount of hand waving about morals and principles will excuse software that performs poorly on the user’s system.

]]>