The Driver on Demand project [LWN.net]

The Driver on Demand project is an effort by Andrew Luecke to provide installable device drivers for Linux systems via the HTTP protocol. The project summary says:

Driver on demand is an attempt to ease driver installations in linux. Basically, what happens is that a user plugs any device into the computer, and if a driver isn't found, the client connects to a CGI server, to check if the device is known, and if its not in the database, then the driver lookup fails and the user is no worse off then they currently are. However, if the device is found online, the driver information file (similar to .inf's, just XML and more versatile) is analysed. If its built into newer versions of kernels, but theres a driver available, the driver is installed, but the system recommends strongly that the user upgrades their kernel, automatically, otherwise it just installs.

The project overview lists some of the capabilities of Driver on Demand. Here is a quick summary of features:

Drivers are served via HTTP and cgi-bin scripts.
Driver installations are performed via user-based click-to-install operations.
Driver definitions are XML-based.
The system has support for open/GPL and licensed/proprietary drivers.
The software is open-source, it has been released under the GPL.
The software is a combination of Perl and Bash.
Vendors can provide automated and timely driver updates for their hardware.
The project supports driver checksum verification through key servers for security.
Drivers are available in standard binary, source code, and package manager formats.
The software works with the Linux 2.4 and 2.6 kernels, 2.6 is recommended.

The FAQ answers some common questions, and the Quick Start documents the process of getting the software up and running. The documentation is still somewhat sparse, especially in the area of user operations. Apparently, the software will run on most Linux distributions.

The current project status and news page indicate a fair amount of recent progress. Several servers are currently online, and a number of drivers have been submitted. The alpha-one version was released in May, 2004. The alpha-two version is being worked on.

Andrew Luecke noted the current state of the project: "The project already fully supports PCI/YENTA PCMCIA already, and will soon support everything from PCI express to USB. Its primary goal is to allow driver installation in linux to be easier th[a]n Windows."

The author is still developing the software in a mostly solo mode, he plans on accepting patches from the outside after the next release is out. Volunteer help has been requested for some parts of the project. The Driver on Demand project looks to be a very useful addition to the Linux system, we wish the author luck in getting it widely accepted.

(Log in to post comments)

The Driver on Demand project

Posted Jun 10, 2004 10:02 UTC (Thu) by rjw (guest, #10415) [Link]

Sounds like a horrible hack compared to what is going on at freedesktop.org

I think this project would be better served by joining the Hal effort - this could quite easily become a hal client.

The other issue is packaging. This system needs to at least make some attempt to integrate with packaging systems.

The Driver on Demand project

Posted Jun 22, 2004 2:49 UTC (Tue) by auzy (guest, #22491) [Link]

I decided might as well show up and have a say ;)

This software is actually possibly going to use HAL, but at its current form, there is a bug in HAL (which the programmers have already said they will fix), which prevents me using it.

About packaging, its designed to be able to take advantage of packages, if they are available. The reason I'm not going to use a specific one though by default on the servers is that if I use ebuilds, gentoo people will complain, if I use apt, vice versa, and finally, if I dont include RPM support, many other people people complain. So, I do allow the user to specify their package management systems, and the db stores available packages for each distro. So if you want to apt-get your stuff, the advantage of this is that it would tell you what to apt-get, so it could just tell you apt-get zonix-driver.

At the very least even if the user doesn't want to get stuff automatically installed, they can just run driverondemand when they want to know where to get a driver for a device they have just installed, so they can install it themself.

In terms of security, the whole system is more secure then the current one because of automated MD5 checks, and digital signature verification (as well as blacklisting abilities).. Ratings are also used. On the current system, I could upload a page with trojans extigy drivers, google would notice it, and I'd infect everyone.. Google wouldn't be able to pull down that page either when it is detected. With driver on demand, if someone does that, and its noticed, it can get pulled directly from the database.

Even more, digital certs can ensure that users only get drivers designed by the vendors.

Of course, I'm starting to realise there is no guarenteed way of telling if a device has a driver currently, so it might turn out that we need a registry which installed drivers can register with to inform programs like mine that there is support. Such a registry would also help ivman and similar projects because they would be able to tell what userspace programs a device supports when they are added, or what to do. That of course would need a large collaboration effort to standardise (which I'm going to start trying to do)

The Driver on Demand project

Posted Jun 10, 2004 23:26 UTC (Thu) by fjalvingh (subscriber, #4803) [Link]

Nonsense. This is a very good idea, provided you get security straight (which is doable). It would actually be better than Windows (and heaps better than just googling the web for the driver, compiling it etc)...

It's the same security exposure we have today, automated

Posted Jun 11, 2004 20:50 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Gak ! Automatic installation of kernel code downloaded from some random network site ?

That was my first reaction, but then I realized it's just the same as what we do today, minus all the hassle.

Today, you find out your device doesn't work, so you read some documents or find a web site or ask on a mailing list and get the URL of some random network site that has kernel code on it, and follow instructions to add it to your kernel.

Don't think that the human user is inserting any intelligence into this process. The typical user doesn't have any to insert.

It reminds me of the software on the Windows system I use at work that thwarts viruses by popping up and asking me for permission every time an unknown program tries to access the Internet. As a Windows nonsophisticate, I have no way to separate the viruses from the legitimate programs based on the information in that message, so I have no choice but to say "yes" every time. At least once (I know now), it was the Netsky virus.

Binary compatibility of driver modules

Posted Jun 11, 2004 13:46 UTC (Fri) by mrshiny (subscriber, #4266) [Link]

I think the biggest challenge will be to deal with issues of binary compatibility. There are so many versions of the kernel with slightly different binary compatibility; keeping track of which modules go with which kernels will be a problem. The only way around this would be to make the user compile the drivers (this could be automated) but this adds a large amount of risk since it will depend on appropriate compiler tools, kernel source, and kernel config info being available.

If the kernel team and the distributions had a stronger commitment to binary compatibility across kernel versions, this would be more likely to succeed.

Anyway, I guess this problem is solvable for the most interesting cases, but we won't be able to achieve the level of success that Microsoft has, since their kernel's ABI changes so infrequently, and they have far fewer kernel variations to deal with.