Re: Automatic download and installation of drivers.

[Stamatis Mitrofanis <ewstam@softhome.net>]

Dmitri wrote:

>Quoting Greg KH :
>
>>On Thu, Oct 18, 2001 at 01:31:17AM +0200, Tim Jansen wrote:
>>
>>>You wouldn't need this in the kernel for automatic downloads. Actually the 
>>>idea of automatic downloadable drivers is to provide drivers that are NOT in 
>>>the kernel. If the user connects a new device and the system doesn't find a 
>>>driver for it it would request one from some server. This server could either 
>>>provide a driver itself, based the device's vendor and model id, or forward 
>>>the system to the vendor's server which would then try to find one for the 
>>>model.
>>>
>>But how do you resolve all of the previous points I raised about
>>compilers,
>>
>Just yesterday I had to replace gcc 3.0.1 with old but working
>egcs-2.91.66. The C download was just 1.5 MBytes, and C++ was
>only 1.5 MBytes more - though you wouldn't need C++ for the kernel.
>
>This means that gcc is just another dependency that the script will
>resolve before even trying to fetch and compile the driver. The
>size of the required download is acceptable even for modem users,
>and that has to be done only once.
>
>Of course, distributions can make the gcc (suitable for kernel
>compilations) a required (base) package.
>
I agree that a C compiler is a nice thing to have, but no one must be 
forced to have it (say, end users). If it becomes a "base package", 
every computer must have it installed and then people will start using 
it when it's not necessary (huge mess). The best thing to do here is to 
install the right version of gcc on demand (just as we do for drivers).

>>.config files,
>>
>I think they are available in "kernel-devel" package or something
>like that. They easily can be shipped as part of the kernel RPM.
>The kernel-devel package is already available in RH, for example.
>
>Of course, the kernel itself can contain a copy of its own .config
>file and export it through /proc fs, along with all compiler options,
>that would be neat :-) and only requires an optional module.
>
Standardize _both_ as the "current kernel configuration" 
(/usr/src/linux/.config _and_ a proc fs entry) so that driver sources 
can freely use it. I'd go for the first one though, here's the rationale:
Since we are going to allow third-party kernel drivers to be compiled 
for a kernel, we may as well grant them the right to do everything that 
a "normally" (in-kernel) distributed driver can do. A driver may depend 
on other drivers to compile/work and they will need to be downloaded, 
configured and installed as well. A driver must be allowed to set (its 
own, of course) entries in the kernel configuration file , modifying it 
for other third-party drivers to read. Thus it's better to use 
/usr/src/linux/.config .

>>in kernel apis,
>>
>That's not something new. APIs change all the time, everywhere, not
>only in OSes. Programmers just need to use #if ... #endif and maybe
>the driver should be marked as "suitable" or "tested" on some range
>of kernel releases.
>
Couldn't the kernel's configuration file be useful in solving this 
problem? API authors could use it to describe the changes they made in 
the API.

>>and security with regards to "automatic downloads"?
>>
>Linus already signs his kernel releases. There is no reason why
>driver maintainers can't join the web of trust. Then GPG will
>cheerfully accept signatures of partially trusted signers. It is
>very easy to do, publishers only need to get their public key
>signed by many other publishers, and the threshold for the sufficient
>trust can be hardcoded to be fairly high.
>
I wish I could find something wrong with that... Then I would have 
something to say here. :-)

>/***/
>
>It is clear to me that Linux needs a mechanism for fetching and
>installing 3rd party drivers. The proposed technology seems to
>be quite simple, and requires very little development because
>all components are already here. I think, a single script can
>definitely accomplish searching, downloading, compiling (kbuild?)
>and installing the driver. This project is all about organizing
>software and people to do it right.
>
Yep. Our slogan should be: "Do it when you have to!". :-)

This script can very well be a hotplug agent supporting four ACTIONs. I 
posted a message about this a few days ago, but since I didn't put any 
Subject line no one must have read it. Here it is again:

/* Quote myself: */

Well, a "configure" script would be good to use for source code. It
would return success/failure depending on whether the local
architecture/configuration is known to work for compiling the driver. If
it's not, then manual compilation and installation is required. Drivers
should be tested on as many kernel versions as possible and the
"configure" script should do any necessary tweakings to make the driver
compile on the particular system (as GNU apps do).

By "format" I didn't refer only to a file format that drivers are
packaged in but also to certain semantics -- like "how is this package
compiled and installed?". So, a driver that comes in source code in a
.tar.gz  and has a "configure" script that must be run before make is in
different "format" than a .tar.gz that doesn't need "configure".

Also, installation of a driver should have its mirror (uninstallation)
as well. Of course, it's not very practical to install/uninstall a
driver every time it's devices are plugged/unplugged, so it should be
left to the user to uninstall the driver when necessary.

pcimodules should do the high-level management for downloading and
installing a driver. It contacts the server to find out where the driver
is, downloads the "resource" and then passes control to a specific
"resource agent" which can install/uninstall this kind of resource.
Resource agents are placed in /etc/hotplug/driver and they accept:
ACTION={install,uninstall}
RESOURCE=/filename/of/resource.extension
TYPE={tarball,tarball_gnu,...}
That also suggests adding a new "driver.agent" to be called by
/sbin/hotplug .

If no one is willing to work on this, I'll try to set up some
client-side scripts on my localhost.





_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel