Linux-hotplug-devel digest, Vol 1 #144 - 5 msgs
From: Keith Owens <[email protected]>
Quoted 9 lines
Quoted 6 lines · Stamatis Mitrofanis
... 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...).
Quoted 7 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel