From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stamatis Mitrofanis Date: Wed, 10 Oct 2001 19:47:08 +0000 Subject: Re: Linux-hotplug-devel digest, Vol 1 #144 - 5 msgs Message-Id: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org From: Keith Owens >On Mon, 08 Oct 2001 01:05:45 +0100, >Stamatis Mitrofanis wrote: > >>... a server will return info about how the client can >>find appropriate driver software (like a precompiled kernel module >>packaged together with appropriate driver agent scripts... or the source >>code for a kernel module... maybe a ready-to-install >>RPM/Debian/Slackware package...). >> >A precompiled kernel module will not work, trust me on this. Modules >must be compiled with the same config options, with a compatible[*] >version of gcc, for SMP or non-SMP and for multiple architectures. The >only way that will scale is a source driver. But that assumes that >everybody using the server has a current set of sources and config for >their kernel. > 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