Network protocol for linux-hotplug.

[Stamatis Mitrofanis <ewstam@softhome.net>]

It had occurred to me that it might be a good idea to make things such 
that unsatisfied hotplug requests are forwarded through the network to 
certain database servers. A client would describe a 
hotplug-subsystem-specific piece of hardware (not necessarily "hardware" 
though -- the design allows for abstraction, but let's stick to actual 
hardware anyway) and 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...).

Of course, the idea behind all this is the principal idea behind 
hot-plugging: To have the user do ABSOLUTELY NOTHING to have his/her 
hardware devices working besides plugging them in. Thus, the driver 
pointed to by the server should be automatically downloaded, compiled, 
installed, loaded and initialized right after the user plugs in a device 
(otherwise this won't be much of an improvement).

When a policy agent has finished searching the map files and realizes 
that there's no matching driver it can load, it will log that this is 
the case and then pass all relevant information to the general program 
that downloads and installs a driver. If the program returns success 
(meaning that everything has been set up correctly) the agent will 
rescan the map files. The downloader should accept information from 
stdin since it can't guess what env. vars are useful. The reason it 
shouldn't simply output a list of driver names is because "driver names" 
are subsystem-specific (i.e. a policy agent may not be meant to do 
anything with kernel modules but instead work with something different).

The general program I'm talking about though needs not be just for 
downloading drivers from the Internet. It may serve, for example, as a 
front-end (a wizard for X maybe? :-) ) to guide the user through the 
installation of the drivers (from a manufacturer-provided disk for 
example). Of course, it should only fallback to requesting user 
assistance (or, better, not request it at all).

Now, there may be many formats the drivers may be downloaded in. Each 
format will have different installation/uninstallation procedures 
associated with it. An example of a format is the classical "tarball" 
which needs just unpacking, "configure"ing and "make install"ing. We can 
organize this stuff in mostly the same way we organize the policy agents 
(with "resource agents" handling specific formats which will take 
parameters describing the location of the resource and the action to 
perform).

This automatic-downloading system must be very small, very uniform and 
very simple to implement. Questions that need answers:
- What protocol do we use for communication of the user system with the 
server system? (must be well-known and standard)
- How do we organize scripts and programs to do the job?
- What will be the formats for drivers downloaded from the net?
- <insert your question here>

Ideas?



_______________________________________________
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