Women in Technology

Hear us Roar



Article:
  Improving Linux Driver Installation
Subject:   API problem much worse than indicated
Date:   2004-09-10 10:54:02
From:   elanthis
The unstable API provides far worse problems than (clearly) indicated in the article. One solution proposed was to include drivers in the tree earlier - that *DOES NOT* fix the problem!


Imagine this _common_ situation. I install Linux Foo 1.2. It has kernel 2.6.5. Some new hardware is invented, a driver becomes available in-tree, and is released for 2.6.7. Guess what? That hardware does not work with Linux Foo 1.2. Vendors do not distribute all new kernels for their distributions, because due to all the other changes in kernel revisions (far more than just driver bug fixes) and their kernel patching, it would be dangerous to try to push a new kernel out. Instead, Linux Foor 1.2 will only ever have small security and bug fix patches applied. There will never be a 2.6.7 kernel package for Linux Foo 1.2.


However, the kernel API has, of course, changed between 2.6.5 and 2.6.7. There is no way to just go grab a copy of the driver for 2.6.5 and install it. No, you must use 2.6.7. And not "2.6.7 or higher," because higher might break the API again. Just 2.6.7. Since Linux Foo 1.2 will only ever have kernel 2.6.5, the user cannot simply install the driver for his new hardware.


The user, in order to use this new hardware, must upgrade his entire OS. But wait, Linux Foo 1.3 won't be out for another 3 months. The user must instead manually install a new kernel. Assuming that you actually had a user who's willing to upgrade their OS at all, you've now alienated and lost the vast majority of remaining users, because the number of people who even know how to, much less are willing to, manually download and install a kernel (possibly adding various patches for compatibility with their distro's special features) is very, very small in relation to the total number of computer users.


The end result really is that the hardware is useless on Linux in general until 3+ years down the road when everyone is using a kernel newer than 2.6.5. Of course, the users who got burned previously may not be using Linux anymore. And there will be new hardware out that won't work with Linux then, either.


The in-tree drivers do absolutely nothing of usefulness *now*. They only make hardware work for any appreciate fraction of the user population a *long* time after the driver is added to the tree.


The solution requires it to be possible for a user to install a driver for whatever OS they currently have installed. This does *NOT* require ABI stability; it is acceptable to require drivers to be distributed as source and require compilation, so long as there is an easy to use method for doing so. It does require a stable API so that a driver can actually be able to compile without needing to match it to the specific kernel running.


(I imagine a special kind of "Linux Driver Package" with tools that compile and install the packages for the user. Users just click on the driver on the CD that came with the hardware, or from a driver web site, and the GUI tool pops up and does the work, prompting for verification and authorization. This will work even if drivers are distributed as source, so long as all user systems have the basic compiler/development tools installed.)

Main Topics Oldest First

Showing messages 1 through 4 of 4.

  • API problem much worse than indicated
    2004-09-14 13:51:11  CodifexMaximus [View]

    At the risk of being flamed, I must say the following...

    Microsoft has a great idea with their Interface Contract idea. They will create an interface (API) with certain methods and properties; then they will update the interface with new methods and properties WHILE RETAINING THE OLD INTERFACES.

    I suppose some API's in Linux are using this model for backwards compatability but all are not. The idea has good and bad points: good are that old programs will keep running; bad are that api bloat will occur.

    Choose yer poison.

    Microsoft also had another good idea back in 1994: minidrivers. MS realised that alot of the monolithic driver code in Win3.1 was similar if not flat out identical. The only differences were the device specific portions. Therefore, MS implemented the stub (or whatever they call it) that contained the generic code for a device then the minidriver made by the device company completed a full device driver. Simple, easy, concise.

    There may be reasons why one would not want interface contracts and stub modules; at this point, I don't see much of a reason not to have them myself.

    Now for the Driver on Demand idea - I think it's good. There could be a central database possibly at the distro maker's site. It could contain minidrivers for each device (submitted by the device manufacturer) with each device having an ID (I assume they already have this ID) and a database onboard the user's computer to complete the identification and driver selection process.

    Compilation on Demand could be a boon AND a bust depending on the accuracy and testing of the builds. I use Gentoo so I'm comfortable with this model - others may not be.

    There's my buck fifty,
    Codifex Maximus
  • API problem much worse than indicated
    2004-09-13 01:01:12  nmailhot [View]

    Don't be silly. Do you think hardware devices are manufactured out of thin air ? There is a large window between hardware design and appearance where drivers can be written, vetted and included in the source kernel tree.
    <br/>
    And the more innovative a device is, the more it is true (for stupid variants you have just to add a hardware PCI/USB id to the already-written driver).
    <br/>
    In fact drivers have been written in the past for top-secret devices not yet aven announced, even full subsystems were included before for yet-to-be released standards. Kernel inclusion is only a problem for lazy vendors (and those won't maintain correctly their out-of-tree trash anyway)
  • API problem much worse than indicated
    2004-09-12 06:24:57  CharlesEllis [View]

    Another solution to this situation is to be a bit more windows like...

    For the more user-friendly distributions, instead of having 2.6.5 and 2.6.7 and 2.6.8, etc. They could release a new version of the distro for 2.6 (presumably this would be the last new version to the 2.6 tree), and then release another version of the distro for 2.8

    I realize that this is not the best solution in the world, however it has been proven to work with the commercial OSes, and would help driver compatibility for those not willing/not knowledgeable enough to compile drivers specifically for a specific version of the kernel.
  • API problem much worse than indicated
    2004-09-12 03:40:17  Dragonheart73 [View]

    Dosn't the latest detonater-Driver original from nVidia follow a similar approach?
    You have the Kernel-Sources to be present, but no more user action is required than calling a shell-skript. Then the driver is compiled and installed.