From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Mon, 29 Oct 2001 21:53:40 +0000 Subject: Re: Automatic download and installation of drivers. Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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