Re: [ANNOUNCE] hotplug-ng 002 release

Per Liden
2005-05-10T22:17:58Z

On Mon, 9 May 2005, Per Svennerbrandt wrote:

> * Per Liden (per@fukt.bth.se) wrote:
> > On Fri, 6 May 2005, Greg KH wrote:
> >
> > [...]
> > > Now, with the 2.6.12-rc3 kernel, and a patch for module-init-tools, the
> > > USB hotplug program can be written with a simple one line shell script:
> > > modprobe $MODALIAS
> >
> > Nice, but why not just convert all this to a call to
> > request_module($MODALIAS)? Seems to me like the natural thing to do.
>
> I actually have a pretty hackish proof-of-consept patch that does
> basicly that, and have been running it on my systems for the past five
> months or so, if anybody's interested.

Ah! Please post the patches.

> Along with it I also have a patch witch exports the module aliases for
> PCI and USB devices through sysfs. With it the "coldplugging" of a
> system (module wise) can be reduced to pretty much:
>
> #!/bin/sh
>
> for DEV in /sys/bus/{pci,usb}/devices/*; do
> modprobe `cat $DEV/modalias`
> done

Nice! This is really what coldplugging _should_ look like. Hmm, maybe
even coldplug the system by request_module()'ing those as well at some
stage?

> (And I actually run exactly that on my laptop, and it works surpricingly
> well. (Largly due to the fact that the usb-controller is always attached
> below the pci-bus of course, but it really wouldn't take that much work
> to make it do the right thing even without relying on any specific
> ordering/topology))
>
> With the above in place my system does all the module-loading that I
> care about automaticly, and most importantly does so without relying
> on an /etc/hotplug/ dir with everything and it's grandma in it (or at
> least thousands of lines of shellscripting).

This is exactly what I'm looking for as well.

> But since the request_modalias() thing seemed as such an obvious thing
> to do I have been reluctant to submit it fearing that I must have missed
> some fundamental flaw in it or you guys would have implemented it that
> way a long time ago? (at least since Rusty rewrote the module
> loader). Was I wrong*?
>
> Greg, Rusty, what do you think?

I'd like to get a better understanding of that as well. Why invent a
second on demand module loader when we have kmod? The current approach
feels like a step back to something very similar to the old kerneld.

/Per L