From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stamatis Mitrofanis Date: Mon, 08 Oct 2001 00:05:45 +0000 Subject: Network protocol for linux-hotplug. 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 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? - 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