Articles / Speeding up Linux Device Dr…

Speeding up Linux Device Driver Development

Linux often sits far on the trailing edge of hardware support and plays catch-up on everything from USB to video cards. Vlatko Kosturjak offers his thoughts on how to improve the situation so new hardware is usable under Linux ASAP. Recently, I got a Logitech USB Web camera which I wanted to use with my laptop, which is running Linux Mandrake. I eagerly connected it. The USB daemon recognized that I had plugged in a device and tried to find a module which would be suitable for it. Unfortunately, none was found. At that point, I knew Hell was waiting for me. I searched the Web and Usenet for information on how to make my new camera work under Linux, but with no luck. I read the kernel documentation about Logitech Web cameras. I even found some support, but only for the parallel version. The documentation also stated that Logitech refuses to give any specs or info on their products. I downloaded the 2.4 kernel, compiled and installed it -- but still with no luck. I even thought about modifying that parallel driver to support USB, but had no time for that.

As an average programmer, I'm skilled enough to make necessary modifications to the kernel, but an average desktop user surely won't cope with it; he has problems even with compiling downloaded kernel source. In order for Linux to become a desktop OS, this should be fixed very soon.

Not very happy with the situation, I decided to write this article and share some ideas on how things should be done to improve device drivers for various hardware devices under Linux.

First, let's face the current model of Linux device drivers: Most drivers are shipped with the kernel source already. A small number of them comes on various CDs, either in binary or source form. Those, however, are usually outdated. While the process of writing a device driver, making the required hardware, copying software CDs, and releasing goes on, time passes. Meanwhile, new versions of the kernel are released, with the latest-and-greatest fixes/features and also with a new-and-improved API for device drivers which is, of course, incompatible with the old one.

So I thought about making a universal API for device drivers in the Linux kernel core that wouldn't change for a long time. If it ever needs to change, the old API should be preserved for compatibility. The standard API means that I can both compile the source (with same headers/function calls) and load the binary module of a certain device driver under any Linux version.

Perhaps this concept should be adopted by other free OSes as well (*BSDs, for example), so that device drivers can become more and more universal as more OSes adopt the concept and standard.

Resolving platform-specific issues could be done through a top-level device driver API that would be translated to some bytecode variant, just like Java. This would mainly be intended as a temporary solution for close-minded companies; it would just buy time while companies that don't recognize the power of Open Source come to their senses. If that would take too long, a just-in-time driver compiler could be implemented that would speed up the driver itself (just like a JIT compiler for Java). That would make close-minded companies happy enough to release drivers, but their drivers won't be as fast as those of their competitors, who published them in source form. This could lead the closed source company to release their drivers in source form too. Voila! We'll soon have an Open Source world!

This would greatly speed up kernel core development as well as device drivers development because most of the drivers would be developed and shipped separately from the kernel source. A single developer could concentrate on writing either core or device drivers, whichever he's currently working on. It is also easier to debug such code. I emphasize that the process of developing and testing drivers would speed up because you could first test them with the specialized driver API, and then rewrite them into fast C/C++/asm variants.

If Linux wants to be the OS for an average desktop machine, some of these points must be taken seriously until the world becomes fully Open Source. If not, maybe some new Open Source desktop OS should take these ideas for realization.

Recent comments

14 Mar 2006 20:48 Avatar vikramkg

Accessing the device file

I am new to the devcie driver .. i need to access the hard disk directly without the the help of the file system ... and my project is just making the mark of the canged block in the hard disk

25 Jul 2001 12:41 Avatar kost

Re: don't be dumb

> The best way to speed up linux driver development
> is to not buy stuff that doesn't have a linux driver.
> Hit the companies where it hurts. Don't be stupid and make % sure something works before you buy it.
> You should have bought a diffrent camera. I'm sure
> there is one that works. I really do not feel sorry for you in
> any way. Most people who have problems with
> hardware under linux do not cause themselves
> problems. Usually it's hardware they have had before
> they started using linux, not after.

Heh, I usually don't buy hardware that is not
supported under Linux, but that camera I got for my birthday ( I DIDN'T bought it), so we have a problem, but we didn't solve it... :-)

09 Mar 2001 08:51 Avatar x400

Re: Why wont companies give out information on devices?

> Can anyone really see a good reason for
> a hardware manufacturer to not give out
> information on protocols?
> Is it because they think people will
> steal their ideas?
> Is it because they don't own the
> protocols?
> Does anyone know of a website where I
> can state my opinion about companie's
> not releasing the information to write
> drivers? If there isn't I may well
> create one.

Ummmm, because they have a serious insecurity problem and they don't know what a REAL Operating System is.
Life would be much easier for all of Linux users if we had our "hands" on it.(if u get my drift).

06 Mar 2001 03:50 Avatar doudou

Re: Closed but freely available source code?
(sorry, i' very bad in english)
At least one company do that already: nVidia. You can download SRPMS for nVidia's DRI kernel driver and compile it for your own kernel. It worked well on my computer.

> If a company made a linux driver for
> hardware, it wouldn't neccessarily have
> to be binary compatible for that kernel
> - source but maybe not binary.
> There could be written a program that
> detects hardware and, if there isn't a
> locally available driver, looks at an
> internet database of drivers. The
> drivers would be in some kind of
> encrytped(perhaps) source code so that a
> companie's precious secrets could be
> left intact. It would then download and
> install the driver without letting the
> users at the source code.

04 Mar 2001 11:24 Avatar jwreschnig

I figure this might be relevant
FSF's view on UDI (which is a superset of
what's being proposed here).


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.