Network protocol for linux-hotplug.

DISCUSSION Stamatis Mitrofanis 5 participants 5 messages Oct 8, 2001

Share & tools

Stamatis Mitrofanis

author

2001-10-08 00:05 UTC #0 lore raw

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Keith Owens

2001-10-08 01:50 UTC #1 lore raw

Quoted 5 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...).

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.

I am not knocking the idea, but until you can solve the problem of building and loading modules on the fly, worrying about file formats and download protocols is a waste of time.

[*] Different versions of gcc generate different code for the kernel.
Blindly loading a gcc 2 module into a kernel compiled with gcc 3 or vice versa is a good recipe for Oops.

Dmitri

2001-10-08 01:57 UTC #2 lore raw

In reply to Stamatis Mitrofanis

Quoting Stamatis Mitrofanis <[email protected]>:

Quoted 9 lines

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.
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)

http:// and nothing else. This is because of firewalls and proxies that are capable of handling it. Other protocols/ports are often blocked from leaving intranets. Also, all http:// infrastructure is already available and widely deployed, allowing easy mirroring.

Quoted 1 line

- How do we organize scripts and programs to do the job?

wget http://www.kernel.org/cgi-bin/getdriver?bus=usb&pid=0x1234&vid=0x5678
tar xzvf usb_0x1234_0x5678.tar.gz
cd usb_0x1234_0x5678 && make && make install

Quoted 1 line

- What will be the formats for drivers downloaded from the net?

likely, tarballs - but .rpm or .deb is also OK, as long as the originator of the request asked for them, *and* as long as they are available. This means that the script has to know how to fall back to the tarball.

Quoted 1 line

- <insert your question here>

Add mandatory signatures to all packages, and mandatory checking of said signatures vs. hardcoded list of identities (public keys). This means that only holders of these keys can publish drivers. Otherwise this will be insecure, to put it mildly :-)

Thanks,
Dmitri

Signature · 3 lines

"We all know Linux is great...it does infinite loops in 5 seconds."
  (Linus Torvalds about the superiority of Linux on the Amterdam
   Linux Symposium)

Randy.Dunlap

2001-10-08 14:22 UTC #3 lore raw

In reply to Stamatis Mitrofanis

Quoted 30 lines · Dmitri

Quoting Stamatis Mitrofanis <[email protected]>:
Quoted 9 lines
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.
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)
http:// and nothing else. This is because of firewalls and proxies that are capable of handling it. Other protocols/ports are often blocked from leaving intranets. Also, all http:// infrastructure is already available and widely deployed, allowing easy mirroring.
Quoted 1 line
- How do we organize scripts and programs to do the job?
wget http://www.kernel.org/cgi-bin/getdriver?bus=usb&pid=0x1234&vid=0x5678
tar xzvf usb_0x1234_0x5678.tar.gz
cd usb_0x1234_0x5678 && make && make install
Quoted 1 line
- What will be the formats for drivers downloaded from the net?
likely, tarballs - but .rpm or .deb is also OK, as long as the originator of the request asked for them, *and* as long as they are available. This means that the script has to know how to fall back to the tarball.

Quoted 6 lines

Quoted 1 line
- <insert your question here>
Add mandatory signatures to all packages, and mandatory checking of said signatures vs. hardcoded list of identities (public keys). This means that only holders of these keys can publish drivers. Otherwise this will be insecure, to put it mildly :-)

I must strongly agree with Dmitri's last statement. Without some form of security checking, this scheme is a huge open hole for danger.

But like Keith said, source code is the only form that scales and works on all types of platforms, at least right now.

~Randy

Tim Jansen

2001-10-08 19:01 UTC #4 lore raw

In reply to Stamatis Mitrofanis

Quoted 6 lines · you

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.
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.

In general it would be a good idea IMHO to have hooks for other applications in the hotplug scripts. My problem with the current solution is that it is not possible to interact with the user. For example if a KDE user plugs in a new mass storage device he should be asked in which directory the device should be mounted, and then possibly konqueror should be opened with the new directory. And Gnome people probably want something similar for Nautilus. So far the hotplug system only works with pre-configured devices.

Quoted 3 lines

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.

In some cases this is a good idea, but often the user also needs applications to use the device. For example if you install a scanner it would be nice to propose some applications for configuring the device.

bye..