Re: Linux-hotplug-devel digest, Vol 1 #144 - 5 msgs

Re: Linux-hotplug-devel digest, Vol 1 #144 - 5 msgs

[Stamatis Mitrofanis]

From: Keith Owens <kaos@ocs.com.au>

 >On Mon, 08 Oct 2001 01:05:45 +0100,
 >Stamatis Mitrofanis <ewstam@softhome.net> 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