[lkml]   [2005]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] hotplug-ng 002 release
    * Per Liden ( wrote:
    > On Mon, 9 May 2005, Per Svennerbrandt wrote:
    > > * Per Liden ( 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.

    Ok, so I finally decided that it's probably silly of me to hold of a
    working patch just because I wanted my first submission to the kernel
    to somehow be a marvellous example of ellegancy and not just some
    quick hack that I threw toghether as a personal proof-of-consept.

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

    Well, the code already generates all the requests necessary. :) The only
    problem now of course beeing that it generates those at a "stage" ;) when
    userspace usually isn't ready to fullfill those.

    I'm currently thinking about maybe making all the requests sleep on a
    waitqueue untill the root filesystem becomes availible, shoudn't be too
    hard if I remember the code correctly... Could potentialy end up using
    a lot of resourses though.

    And, yeah, I know this could all be done quite easily with scripts in a
    initrd or similar, but that is in fact *exactly* what I'm trying to
    avoid here, to reduce complexity and keep thinks as simple as they
    possibly can be. I'm not proposing this as a generic solution for
    everyone, rather the opposite in fact. I do however beleve there to be
    enough demand out there for this particular kind of "special case" to
    warrant (optional) support for it in the mainline kernel.

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

    For example, I see absolutely no need for a fullblown hotplug system
    on my minimalst-userspace router/firewall. I just want the kernel to
    be able to load the right modules, on demand, as it boots (and perhaps
    when I plug in a usb flashdrive, every third, or so, year).

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

    Sorry for the delay, patches to follow.

    / Per Svennerbrandt
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-19 01:05    [W:0.024 / U:34.960 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site