Re: Automatic download and installation of drivers.

[Greg KH <greg@kroah.com>]

On Thu, Oct 18, 2001 at 01:19:47AM +0100, Stamatis Mitrofanis wrote:
> 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).

And what version of gcc would you install?  Different versions for
different vendor kernels and even releases  :)

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

The /proc .config argument has been answered by Linus.  So you can't
guarantee that it will be available unless you apply a third party patch
to your kernel.

But I don't keep my kernels in /usr/src/linux, and neither do most
people.  And vendor kernels include a number of different .config files,
all of them placed in a different file within the .src.rpm.  Work with
the LSB if you want to push for this kind of standardization.

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

No, the .config file is used to describe the options that the user wants
built for the kernel.  It is not a language that can express API
changes.

How would you describe the fact that between kernels x and y, the struct
usb_serial_device changed the field "lock" from being a "struct
spinlock_t" to being a "struct semaphore"?  Changes that that _have_ to
have code changes to the driver made.  That's the main problem that you
are going to run into here.

> 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:

Remember /sbin/hotplug runs as root.  You do _not_ want to be doing any
of these actions as root :)

Good luck,

greg k-h

_______________________________________________
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