Network protocol for linux-hotplug.

Network protocol for linux-hotplug.

[Stamatis Mitrofanis]

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

Re: Network protocol for linux-hotplug.

[Keith Owens]

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.

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.


_______________________________________________
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

Re: Network protocol for linux-hotplug.

[Dmitri]

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

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

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

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

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

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Network protocol for linux-hotplug.

[Randy.Dunlap]

Dmitri wrote:
> 
> Quoting 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.
> 
> > 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.
> 
> > - 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
> 
> > - 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.
> 
> > - <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

_______________________________________________
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

Re: Network protocol for linux-hotplug.

[Tim Jansen]

On Monday 08 October 2001 02:05, you wrote:
> 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.

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


_______________________________________________
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