[lkml]   [2006]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers
    On Tuesday 05 December 2006 2:01 am, Marco d'Itri wrote:
    > On Dec 05, David Brownell <> wrote:
    > > The pushback on $SUBJECT patch. Which amounts to wanting to break hotplug
    > > for several busses, unless someone (NOT the folk promoting the breakage!)
    > Please explain in more details how hotplugging would be broken, possibly
    > with examples.

    First, for reference, I refer to hotplugging using the trivial ASH scripts
    from [1], updated by removing no-longer-needed special cases for platform_bus
    (that original logic didn't work sometimes) and pcmcia. See the (short)
    contemporary thread [2] discussing platform_bus support, and some of issues
    related to why its hotplug support works the way it does now. (Looks like
    some messages are not archived, but the key points are there.)

    Those scripts have supported hotplug and coldplug on several embedded boards
    for some time now. The ancient "runs on 2.4" scripts would have been way
    too slow to justify using hotplug and udev to replace devfs, and also needed
    all sorts of extra crap that's regularly not found with embedded Linuxes.
    Plus of course they never understood platform_bus, which is the main way
    those PCI-less systems are hooked together.

    Second, note that you're asking me to construct a straw man for you and
    then break it down, since nobody arguing with the $SUBJECT patch has ever
    provided a complete counter-proposal (much less respond to the points
    I've made about legacy driver bugginess -- which is suggestive).

    That said, the common thread in that pushback is that $MODALIAS (and also
    modalias files) "should" have some value other than ...
    which name is conventionaly also the name of the driver's module. That goes
    along with a (weak) rationale that requires spi_bus and KMOD to change, plus
    (presumably, pending a code audit) other kernel subsystems.

    That should make it clear how accepting that pushback would break hotplug:
    "modprobe $MODALIAS" would no longer load the right module. Likewise
    the more significant case of coldplug; "modprobe $(cat modalias)" would
    likewise no longer work.

    > > There are really two issues here:
    > >
    > > - The "real one", as (yes!) fixed by the $SUBJECT patch. Troublesome legacy
    > > drivers, like "i82365", written so they can't hotplug ... but the kernel
    > > hasn't previously known that.
    > >
    > > - The confusion, caused by a false identification of the "i82365" issue
    > > being a problem related to module aliasing ... instead of being rooted in
    > > the fact that it's a "legacy style" non-hotpluggable driver, since it
    > > creates its own device node.
    > Nonsense. The purpose of $MODALIAS is to allow automatically loading
    > modules using the information provided by the bus driver.

    Without using sysfs. And that's exactly what it does _today_ for the

    Modulo the real issue, which is that legacy/ISA style drivers like i82365 will
    never support hotplugging ("automatically loading modules ..." plus consequent
    device configuration), without first being split into separate bus support
    (making the device nodes) and driver module (the thing $MODALIAS supports).
    Hotplug depends on that split in a fundamental manner.

    So ... on what point were you disagreeing with me??

    > Because of this reason there is no point for a driver to provide a
    > $MODALIAS referring to itself. It will only waste resources causing udev
    > to try loading it again.

    The $SUBJECT patch makes those legacy drivers NOT use the $MODALIAS
    mechanism ... you seem to be overlooking that.

    And "udev" was from day one supposed to solve a different problem
    than "loading modules". There was to be a clear and strong separation
    of roles between hotplug (load modules, don't rely on sysfs, use other
    components for the rest of device setup) and udev (make /dev nodes,
    ok to rely on sysfs). That is, "udev" wouldn't do any loading.

    - Dave


    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: 2006-12-06 01:05    [W:0.025 / U:14.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site