Slashdot Mirror

← Back to Stories (view on slashdot.org)

Simplifying Linux Driver Installation

Posted by timothy on from the please-and-how dept.

prostoalex writes "O'Reilly Network posts an update on Project Utopia that produced Hardware Abstraction Layer for Linux simplifying device changes. They also link to the Driver on Demand project on SourceForge, whose goal is to create a central database to enable Linux desktops download the drivers automatically when the user plugs in her new hardware device."

11 of 377 comments (clear)

  1. Won't happen anytime soon... by AntiGenX · · Score: 5, Interesting
    As the article points out Linus is vehemently against making the kernel API/ABI's stable. On the one hand this allows them to add knew stuff all the damn time, but it breaks drivers. In my opinion this is what's holding linux back. It contributes to Linux having crappy hardware support. (Yes it has crappy hardware support people!) Sure it supports LOTS of devices, but a lot of them require some voodoo to make them work. That's all fine and well for people like me, but average users don't want to dick around with modprobe.conf. I'm sure a lot of vendors would be more willing to put out their own drivers if they didn't think they'd have retest/recode every kernel release

    For what it's worth, I'm somewhat sympathetic to Linus. Look at what HAL did for/to Windows. Crappy driver/HAL implementations were responsible for a lot of Windows perceived and real stability problems. Now Microsoft likes to certify drivers (WHQL), so they only take the blame for their own damn bugs.

    Basically, it's a double-edged sword. Convenience vs. Stability. Personally, I think if Linus is serious about the desktop there needs to be some compomise. Me, I just dumped Linux on the desktop for my sweet new OS X system. Viva la UNIX!

    1. Re:Won't happen anytime soon... by Spy+Hunter · · Score: 4, Interesting
      The problem is, Linus is letting his pursuit of one goal (encourage open-source drivers) hurt progress toward another (stable, user-friendly drivers for every single device out there). Changing the kernel APIs all the time does encourage open-source drivers, and it allows easier kernel innovation, but it has many, many disadvantages:
      1. It requires changes in many drivers for every single kernel release, which takes valuable developer time.
      2. It makes drivers less stable and testable due to the constant changes they must undergo.
      3. It discourages driver development outside of the main kernel tree, which in turn...
      4. bloats the main kernel with too many drivers.
      5. Upgrading the kernel requires an upgrade and recompile of every driver you use, or you risk incompatibility or instability.
      6. It is nearly impossible to have a database holding every driver you might need for a desktop Linux system.
      7. Hardware detection and setup software requires constant changes to keep up with drivers and because of this is often unreliable.
      I'm sure I could think of more disadvantages too, given enough time. Given the number and magnitude of these problems, it should be Linus's top priority to find a different way of encouraging open-source drivers, so that these problems can be solved. Changing the APIs willy-nilly can't be the only way to encourage open-source.

      If Linus won't listen to reason, I propose it's time for a kernel fork. Nothing less will solve Linux's driver situation, and it does need solving. Linus himself has already said that the 2.6 kernel isn't "stable" as such, and it's the responsibility of distributions to ensure that their kernels are stable. I propose that the distributions take Linus at his word and cooperate on forking the 2.6 kernel into a "stable" version with a focus on stable, user-friendly drivers and driver installation. Then Linus can remove a ton of irrelevant drivers out of the core kernel and focus on improving the guts for the next major release, while the rest of us enjoy better hardware support.

      If Linus wants his tree to be a permanent development tree, so be it. The core kernel has now improved to the point where it is good enough for 99.9% of users, so further improvements in the development tree are becoming less and less relevant to Linux distribution users. Drivers are what users look forward to improvements in, not the kernel.

      Closed-source drivers are still a concern, but I'm convinced that there are better ways to encourage manufacturers to open their source. Linus's way is not the only way.

      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
    2. Re:Won't happen anytime soon... by don.g · · Score: 4, Interesting

      Show me a modern inkjet printer that needs a kernelspace driver, and I'll show you a very very very surprised me.

      --
      Pretend that something especially witty is here. Thanks.
  2. Re:Wating for this by ozric99 · · Score: 4, Interesting
    Also when will the major heads of the different distros define a single good, method of packaging programs.

    Just as soon as KDE and Gnome merge, and XP gets Final Cut Pro - never gonna happen.. too many egos in the way.

  3. Wrong problem by Anonymous Coward · · Score: 4, Interesting

    It is obvious that I as an corporate user, would refuse to install *anything* on my Linux system that has not gone through my distributor. After all, that's why I pay them. And pushing third-party binary modules in my running kernel would be a very quick way of nullifying their support agreements.

    For the home user, things might well be different. But most people are running a distribution anyway, and would probably feel more comfortable getting drivers from them. That's how they get the security updates, so both the trust and the technical procedure is already in place. So if the distributors are to share the workload of getting these drivers, then a open project may be the right way -- but only for distributing the module source. Not many users would get drivers from here (Gentoo users come to mind).

    The article has an ivory-tower stance to it and I think they solve the wrong problem. First we need to establish what the problem actually is. If the drivers are few and small then all drivers could be included in a typical distribution and updated with the rest of the system. Perhaps all that is needed is for distribution to update their kernel packages more often?

  4. Probably no reverse engineering by anti-NAT · · Score: 4, Interesting

    Question for the Kernel coders, what perctage of drivers are reverse engineered?? 60-70%

    The percentage would be near 0% if not 0%. Plenty of hardware manufacturers have released open or open-enough programming specifications for their hardware. Intel, AMD and National Semiconductor are a few examples.

    For example, here are the programming specifications for my network card, a Netgear FA312 - DP83815 10 100 Mb s Integrated PCI Ethernet Media Access Controller and Physical Layer (MacPhyter)

    Companies like NVidia and ATi are the exception, not the rule.

    --
    The Internet's nature is peer to peer - 20050301_cs_profs.pdf
  5. Re:Neat! by Sique · · Score: 4, Interesting

    Hardware Abstraction Layers are VERY old. Even the 6502 based Commodore computer series (PET, VC20, C64 et. al.) had some kind of HAL, it was called the Kernel ROM, and developers were strongly encouraged to use the I/O-Routines provided by the Kernel ROM instead of writing their own.

    The whole point of the VM/CMS operation system from IBM was hardware abstraction. That's where the name comes from: Virtual Machine CMS. VM/CMS was providing an abstract CMS system (CMS being the predecessor of VM/CMS) for each process or task, so you could use multiple virtual CMS systems on your hardware.

    Just because WinNT uses hardware abstraction doesn't make it an innovative idea from Microsoft.

    Same about KDevelop. Ever used an OSF Motif Toolkit? They are around since the early days of Motif (around 1988), and the Visual series from Microsoft could easily be called an ripoff. Not to forget the Turbo Pascal/Borland Pascal/Delphi IDEs or again IBM with the VisualAge series of compilers.

    The real power of Microsoft is not innovation, it is the sheer manpower and organisation they have to integrate ideas that proved to work into a single, quite coherent system (even though in the beginning, Microsoft's offerings didn't integrate very well into each other... The first MS Office suites for instance had different file dialogs in every program, and different ways to set up the printer... but it got better every version).

    And for becoming "more and more similar to Windows": If the default installation is in a substantial way different than Windows, the whining goes: "Steep learning curve! It's too different!". If the differences are hidden, then the whining is: "It's becoming more and more Windows! Where is the innovation?" It seems as if the GUI developers have to choose between Scylla and Charybdis here.

    --
    .sig: Sique *sigh*
  6. Re:Neat! by MBCook · · Score: 5, Interesting
    I agree. Windows has gotten MUCH better over the years. But I have noticed one thing that consistantly forces me to reboot my computer: disk activity. I can run my computer for weeks doing normal things and have no problem (XP Pro, 900mhz, 512mb for the record).

    But disk activity kills the machine. It's a laptop, so disk access is a little slow, but if I work with large files (open, close, save, copy, etc) especiallyi zip/rar files (lots of file operations) the system begins to slow to a crawl. Now I understand that the disk activity can slow the computer, but after all the transfers are complete, the computer is still slow. Opening IE goes from near instant (before all that) to seconds of the computer chugging. After that if I close IE and open it again, it still has to chug to open it (so it's not some simple cache thing). The computer is just slow as heck to respond to anything untill I reboot it. At that point it's fine! The same happens after defragging my disk if it's bad (and requires lots of operations to fix it).

    I swear, it's like there is some internal limit in Windows when after a certain number of file operations, the system purposly slows down. Frankly I wouldn't be suprised if a little box popped up saying "You are doing too much heavy disk activity. Please buy Windows Server .Net 2003 for better performance" or something.

    Never happens with Linux on the same machine, so it has to be something Windows is doing. Windows has gotten much MUCH better from the 3.1/95 days, but it still has some problems.

    --
    Comment forecast: Bits of genius surrounded by a sea of mediocrity.
  7. Re:Yeah by Enahs · · Score: 4, Interesting

    Hell, I had trouble with a Lexar JumpDrive (a USB solid-state storage device) today on Windows XP. Had the thing in my pocket, at my parents' house, and they wanted me to touch up a photo but seemed reluctant for me to take the original. OK, no problem. So I sat down at their computer, fired up their image-editing software, and set the scanner to scan at 1200dpi, grayscale. Then:

    1. I plugged in the Lexar JumpDrive.
    2. I went to My Computer, and was delighted to learn that the JumpDrive hadn't been detected.
    3. Unplugged the Lexar JumpDrive.
    4. Went into the Control Panel and Device Profiles, only to find that some sort of obscure-sounding USB device was misconfigured. Since they have a largely from-the-factory-setup Dell, I thought that had to be my hardware. Let Windows search for the drivers; it failed.
    5. Plugged in the Lexar JumpDrive.
    6. Unplugged the Lexar JumpDrive.
    7. Plugged in the Lexar JumpDrive.
    8. Restarted the XP machine, because my parents said they'd had the machine "acting squirly for a while."
    9. Waited for restart, opened My Computer.
    10. Unplugged the Lexar JumpDrive.
    11. Went to the Lexar website looking for 3rd-party drivers. None available or needed.
    12. Plugged in the Lexar JumpDrive.
    13. Went to the Dell website. Waited for an eternity for the site to load.
    14. Unplugged the Lexar JumpDrive to get a specific model number, and typed it into a Search box.
    15. Plugged in the Lexar JumpDrive.
    16. Raise an eyebrow since the device was autodetected and properly configured without human intervention.

    Contrast this with my experience with a relatively user-unfriendly Linux install:

    1. Plug in the Lexar JumpDrive.
    2. Do some command-line magick to find that it's set up as /dev/sda1.
    3. Edit /etc/fstab.
    4. Set up a KDE device icon.
    5. Click on the icon. Note: from now on, clicking on the icon mounts the device and opens a Konqueror window, while right-clicking gives me an unmount option.

    Or, on Mac OS X:

    1. Plug in the Lexar JumpDrive.

    --
    Stating on Slashdot that I like cheese since 1997.
  8. Seems like a solution at the wrong place by pspinler · · Score: 4, Interesting

    The real problem isn't the kernels and the device support therein, rather, its the devices. Really, how many different ways do you need to send data to a printer, or a disk, or get images off a digital camera or webcam, or sound to and from a soundcard, or a 3d command pipeline to a vid card ? The plethora of different device interfaces for substantially identical devices is the real problem.

    Instead, I think there should be a (small set of) _device_ standards.

    That is, something like a architecture standard: a standard category of devices which the manufacturers will agree to provide standard interfaces for

    Combine that with a standard, architecture independent way of allowing devices to carry their own drivers. Perhaps something like a fast Forth like bytecode interpreter.

    Maybe not the best approach, but a lot better than what we have now.

    -- Pat

    --
    The biggest problem with communication is the illusion that it has occurred
  9. Protected libraries by mrogers · · Score: 5, Interesting
    What's needed is a hybrid between a library and a process - call it a protected library. It has its own privileges and its own data segment, like a process, but it doesn't have any threads: it exports an API and uses the caller's timeslice and stack segment, like a library.

    You could, for example, have a graphics library that was setuid root, to allow non-root users to access the graphics hardware through a rectricted API.

    This gives you the advantages of a shared library (no context switching, driver is distributed and managed separately from the kernel) without the disadvantages (processes must run as root because the library requires root privileges to access the hardware). There's only one disadvantage that I can think of: all arguments must be passed on the stack because the caller and the protected library have different data segments. If the protected library can be given access to the caller's data segment as well as its own, that problem disappears - the 386 supports six segments so that should be possible in principle. But passing arguments on the stack might be a better solution because it would allow arbitrary nesting of protected libraries.