Simplifying Linux Driver Installation

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."

Comments

Won't happen anytime soon...

[AntiGenX]

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!

Re:Neat!

[MBCook]

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.

Protected libraries

[mrogers]

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.