LWN.net Logo

Improving Linux Driver Installation (O'ReillyNet)

O'ReillyNet wants to improve Linux driver installation. "When compiling the kernel, you can select the drivers you want to use. Linux also has the capability to compile most drivers into special modules that it will load only when you use the device. These loadable modules allow the kernel to load certain drivers only when needed. This is particularly handy with rarely used devices and removable USB peripherals. Although loading drivers on the fly is flexible, the user experience of dealing with drivers has required that users know how to deal with modules, mount disks and devices, and low-level device information. These requirements have acted as a barrier to Linux adoption for nontechnical users."
(Log in to post comments)

Improving Linux Driver Installation (O'ReillyNet)

Posted Sep 10, 2004 21:56 UTC (Fri) by madscientist (subscriber, #16861) [Link]

I posted this at oreillynet but maybe it'd be more useful here:

Maybe I missed something. Why does DoD have to download a binary driver (assuming of course that the driver is not proprietary)? Why can't it just download the source to the driver, build it on the user's system, and install it?

Obviously this won't work all the time: if the driver source is too old it might not work with a newer kernel, and some kinds of patches might break some drivers, etc. But it would solve most of the problems relating to distro-patched kernels exponentially increasing the number of binary modules that need to be kept for download, and the DoD could hide all of this from the user and if the insmod of the newly-compiled kernel failed it could report this to the user maybe with a link where they could go to report the problem and get help.

Obviously there are some assumptions here, such as the kernel build needs to support external module builds in a robust way (but I thought 2.6's kbuild did this?); distros all would need to provide at least enough infrastructure to build external modules (which is not all that much really) and a compiler (but just C, not C++/Java/etc.) on every system as part of the base install; distros should release kernels with MODVERSIONS enabled (don't they all do that already?); kernels need to ensure their numbering scheme is lexicographically rigorous so you can associate versions of the driver source with versions of the kernel and pick the most likely fit.

And of course, as mentioned above, this does not much help proprietary kernel module vendors (although if the DoD wished they could allow binary modules to be distributed through the framework on a "best effort" basis, and give the vendor's contact info if the insmod fails instead of the OSS community info). This might even give yet more incentive for vendors to provide source rather than binary.

Just some thoughts...

Improving Linux Driver Installation (O'ReillyNet)

Posted Sep 12, 2004 19:25 UTC (Sun) by mmarq (guest, #2332) [Link]

" Why does DoD have to download a binary driver (assuming of course that the driver is not proprietary)? Why can't it just download the source to the driver, build it on the user's system, and install it? "

Because a larg part of the intented audiance for DoD, i belive, is indoctrinated in so many years of plug&play and ease of installation and use (the next, next & finish BS mantra), that they belive that they know *really* something about computers, when they dont even have the slightest idea of a booting process...

They will strick furiously against Linux, if you demonstrate that they dont know nothing,...

... that is one of the reasons, i belive, there is a very chill reception of Linux from the majority of home/SOHO computer users, strongly stimulated by the thousands and thoudsands of local "White Box" suppliers that in a large proportion dont know more than the users..., Linux intimidate them, it requires knowleadge,... it brings the prospect of having to pay for a proper support..., it could kill a large proportion of "white box" of which i suspect is thriving on illegal instalations of MS Windows and Office,...

... all that if Linux happens to dominate clearly the IT world.


Improving Linux Driver Installation (O'ReillyNet)

Posted Sep 13, 2004 17:18 UTC (Mon) by madscientist (subscriber, #16861) [Link]

I don't follow your comment. My thought was to provide a pointy-clicky interface that would pop up a dialog saying "you need a driver; shall I get one from the Linux secure driver server?" If the user says yes, then _BEHIND THE SCENES_ it will download, unpack, compile, and attempt to insmod the driver. None of this need be visible to the user! He can watch a little progress bar, or something like that. If one of the above steps fails another dialog pops up saying "failed" with a Details button they can use to see the gory details (stdout/stderr output from the process for example). It can provide a website they can go to for more information. It can offer to send diagnostic info (kernel version, compiler version, and the transcript) to the central server, without any guarantee that anyone will look at it (just like you get with other OS's). Etc. etc.

At no time will the "intended audience" need to have their cushy existence disturbed by confusing compiler or module load error messages... unless they want to learn.

Improving Linux Driver Installation (O'ReillyNet)

Posted Sep 16, 2004 12:37 UTC (Thu) by mmarq (guest, #2332) [Link]

" Why can't it just download the source to the driver, build it on the user's system, and install it? "

That is precisely the point. Dont take me rude to point you to the main article on O'Reilly... have you read it, until the end ?

The problem is driver source... DoD "should" always try to download a 'binary *thing* of some kind',... because that binary module could very well be, not the ones that he are used to now in the Linux kernel, but other kind more fit to deal with device drivers...

What has always been, open source drivers from poor documentation, years of trial and error and reverse engineering methods, simple can't keep up with the ever growing complexity... i belive you agree it was easier to chose the MOBO and build a Linux PC 5 years ago with PIII and the 1st Athlon than it is now.

Improving Linux Driver Installation (O'ReillyNet)

Posted Sep 11, 2004 2:27 UTC (Sat) by zone (guest, #3633) [Link]

A well written and researched article, but the premise is fluff.

"The goal of Driver on Demand is that the user should be able to plug in a device and the software will then check whether a device driver module is present. If not, it will download the relevant driver from a secure Internet site and insert it into the kernel."

Correct. The secure Internet site here is the distributor's update server. If a distributor can't offer a comprehensive update mechanism that includes support for the latest hardware, then they don't deserve to be used.

The distributions have a ways to go toward user-friendliness in this area, and there does need to be more distributor coordination with getting out-of-tree drivers into a condition where they can be moved in-tree, but talk about stable APIs/ABIs and universal binary compatibility is not poignant.

"It shouldn't be completely unexpected that in the future, drivers for devices will come on CDs, and at the very least, users will want to be able to just double-click the driver to install it.."

Hardware sits on store shelves for years and with the ubiquity of the Internet and the pace of Open Source development, there is no reason to install a crusty driver off of a CD when you could use the latest version provided by your distributor.

Improving Linux Driver Installation (O'ReillyNet)

Posted Sep 11, 2004 22:46 UTC (Sat) by gvy (guest, #11981) [Link]

Man, have you ever actually tried *automatically* updating kernels?

Please come back with your docs in flying colors if it's so.

I've been running ALT Linux with apt-get in cron(8) on my servers for years, but sorry -- Linux kernel still requires some special handling these days.

As of "additional hardware support modules" -- it's just plain the same if your particular module is inside monolithic kernel package even if it's modular: you have to fiddle with kernel image and a bootloader. It's *not* automatable to the degree of reacting on some device being plugged in.

E.g. I have these on my system:

kernel-image-std-up-2.4.26-alt6
kernel-modules-alsa-std-up-1.0.4-alt4.6
kernel-modules-cloop-std-up-2.01-alt4.6
kernel-modules-lm_sensors-std-up-2.8.6-alt3.6
kernel-modules-nvidia-nforce-std-up-1.0.0261-alt13.6
kernel-modules-nvidia-std-up-1.0.6111-alt1.6
kernel-modules-subfs-std-up-0.9-alt3.6

I can add some madwifi or ltmodem driver by simple apt call, and it could probably even get automated with updates.

But letting the system to go somewhere "just in case"? No thanks, it's called "minor updates" or "last release" and involves some decision-making on behalf of system's owner.

I wouldn't like my printer to go out on a limb to its respective manufacturer to order me some cartridges "just in case" because it "feels" the installed one would get empty while the new one arrives. (heck, if any braindead company actually tries to do that, here's your prior art to feed 'em :)

Improving Linux Driver Installation (O'ReillyNet)

Posted Sep 16, 2004 12:25 UTC (Thu) by evgeny (guest, #774) [Link]

I wouldn't like my printer to go out on a limb to its respective manufacturer to order me some cartridges "just in case" because it "feels" the installed one would get empty while the new one arrives. (heck, if any braindead company actually tries to do that, here's your prior art to feed 'em :)

Too late. Xerox's CentreWare IS has been doing this (though not by default ;-)) for a while.

The thinking here is backwards

Posted Sep 11, 2004 10:21 UTC (Sat) by job (guest, #670) [Link]

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 it is a mistake.
First we need to establish if this is a problem at all. 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?

The thinking here is backwards

Posted Sep 12, 2004 16:10 UTC (Sun) by huffd (guest, #10382) [Link]

"Click, here to install third party unsupported (binary) device driver which may or may not destroy your service contract, desktop, personal settings, introduce a worm into your network and cost you your job".
That should serve as an apprpriate warning label.

Why would anyone want to take the chance of having 320x192 images pilfered from your camcorder stream uploaded to the internet?

I agree completely with the "The thinking here is backwards" post. I'm just taking cheap shots at the short sightedness of the article.

Open Source is Open Source why should it be any other way?

The thinking here is backwards

Posted Sep 13, 2004 1:12 UTC (Mon) by mmarq (guest, #2332) [Link]

" "Click, here to install third party unsupported (binary) device driver which may or may not destroy your service contract, desktop, personal settings, introduce a worm into your network and cost you your job".
That should serve as an apprpriate warning label. "

hmm... some how i belive that would be a preferable risk than

" Sorry! no support available yet for your hardware."

And "we" dont have to wait another 20 years to see the consequences,... thought, i belive the solution lies in between.

The thinking here is backwards

Posted Sep 13, 2004 4:39 UTC (Mon) by huffd (guest, #10382) [Link]

The thread the discussion pertained to corporate application. This "Click here to install driver so I can use the company color printer for my vacation pictures" attitude would be not be acceptable and would be used to thwart plans to penetrate the corporate market. Please focus and stay on task with the discussion.

Improving Linux Driver Installation (O'ReillyNet)

Posted Sep 12, 2004 20:21 UTC (Sun) by mmarq (guest, #2332) [Link]

" The reason a single binary driver will not work across a kernel series is the lack of internal API and ABI (application binary interface) compatibility in the kernel. "

From the limited knowleadge i have of the matter, and from what i can understand of D-BUS...
http://www-106.ibm.com/developerworks/linux/library/l-dbu...
... you could extend D_BUS *down* to deal with hardware device drivers, in a way that it only need to augment the messages types (and other fearures probabily), dealed by D_BUS system to create a messaging based device driver model, similar to how I2O works, and that way pass altogether the need of a proper ABI that could take years to stabilize.

Windows does not have drivers on demand.

Posted Sep 13, 2004 10:10 UTC (Mon) by dps (subscriber, #5725) [Link]

Having actually tried installing windows and the dubious experience of using it to some extent, you rapidly discover either it works or you have *major* problems---much worse than the problems in linux. Even if you actually know the chipset drivers rarely tell you what they support.

I would also note that windows requires you to install drivers for almost everything manually, whereas linux has often worked out what my new hardware is and loaded an appropriate module automagically. Frequently I have installed hadrware and it has just worked on linux, which has *never* happenned for me on windows.

Making things even easier would be nice, but project utopia seems to involve everyone having ulimited unmetered internet access which is simply not true here. Until recently I only had pay-per-minute dailup access :-( I am also worried about getting LKM rootkits widely installed shortly after someone has owned the central repository.

Windows does not have drivers on demand.

Posted Sep 13, 2004 16:29 UTC (Mon) by mmarq (guest, #2332) [Link]

I belive that the DoD centralized model, in a world more and more distributed is just,... a different approach,... and noboby should worry too much about it,... DoD have to evolve because a central repository for everything drivers just would not stick.

Thought, the greatest value of project Utopia, is that it discuss matters that *ARE ACTUALY THE MOST IMPORTANT* in the Open Source area today, inspite the corporate world dont give it the attention it should receive, because it is the heart of "world wide" IT domination.

Perhaps is just me,... but i sense a certain fear from the corporate lidership of Open Source of a certain corporation that dominates the IT paradigma and that is knowned to retaliet against thier own business partners, no matter who, if someone threatens their dominium... and almost everybody *have* to make business with the monopoly...

So project Utopia is IMO the most important one in Open Source on the last years,... because with SMT(hyperthreading)+ CMS(multicore) processors and with NUMA support craved in the chipsets, like the Opteron ones, it seems reasonabily that scalability is heading troward the more and more integration of functionality like VoIP, IM and P2P networks and not the number of physical processores supported.

Windows does not have drivers on demand.

Posted Sep 16, 2004 22:46 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

I would also note that windows requires you to install drivers for almost everything manually, whereas linux has often worked out what my new hardware is and loaded an appropriate module automagically.

It sounds like you may be comparing apples and oranges. There are many steps in getting new drivers going for new hardware. The first step is getting the code on your disk, and I think that's the problem the article is about. A subsequent step is getting your system configured so that it uses a driver that's on your disk with a particular piece of new hardware. A third is loading the driver from the disk into the kernel so you can actually execute it.

I have little experience with Windows or with the Linux systems that are meant to provide equivalent ease of use (Red Hat Linux, etc.), but from what I've seen, they look pretty much the same.

  • Both come with large quantities of drivers, so there's a good chance there's no driver to get -- unless you want something up to date.
  • Both notice new hardware at boot time and ask you if you'd like the system to automatically find and configure a driver for it.
  • Neither will acquire a driver from the Internet if you don't have one already.
  • Windows will take a driver from a CD that came with the hardware. I don't know if Red Hat can do that (not much point, since hardware doesn't come with linux drivers on CD).

Do others have different driver experiences?

Improving Linux Driver Installation (O'ReillyNet)

Posted Oct 31, 2004 20:15 UTC (Sun) by patrickomir (guest, #25770) [Link]

Okay: I've installed Linux libranet yesterday, because I wanted to become independent from Microsoft. Since yesterday I tried to find out how to install a ma111 wireless usb network adapter in linux. I'll try to give you the opinion of an ambitionated (spelling correct? - german mother tongue...) newbie:

Developing counties' scientists frequently use linux for research. I'm in medicine and want to go abroad. So... I have to learn linux. And after all I like the idea of open source/free software. (I will also donate my reseach results to the world, why not consume free software.)

I do have some computer knowledge, but it took me 2 full days, to find out, that I have to recompile the kernel to install a new driver. And it took me quite a time to find out, that I have to unmount my .../cdrom1 - drive to get the cd out again (wanted to install drivers from cd...). That's okay, I can do that, I'm not stupid, BUT I need the right INFORMATION.

So I have 1 message to this discussion:

The newbie will be scared away, if you don't give them a THEORETICAL overwiew of linux.

Especially THEORETICAL differences between Windows and Linux. And we need them at every corner of the Linux - internet. I could imagine a "newbie - first - info" - icon with a THEORETICAL info about Linux (differences to Windows especially) on the most important linux - pages!
I do understand the need to recompile, because of all the distributions, but ONLY after I read through these postings. All the other information was about /rc/etc/config.bla bla bla... A lot too detailed informaiton - useless if you don't know the THEORY

Medical example: If I tell a patient: " The infiltration of an noninfectious epitope will cause your T - memory cells to stimulate B - cells in case of reexpontation of an potentially infectious agens." The patient will walk away and spend his money for some paramedical esoteric "healers" (Windows). OR
I give him some THEORETICAL overview: "If you show your body, how the bacteria looks like, it will be able to respond in case of later infection."
He will get the vaccine AND be also immune against the "healers" :-)

lg Patrick

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds