[lkml]   [2006]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Bulk] Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers
    > > 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. ...
    > Ah, so for the platform devices, doing a
    > modprobe /sys/devices/platform/*
    > would load all of the proper modules for the specific platform devices
    > that are already present due to the MODULE_ALIAS() stuff?

    That's sort of how that original "coldplug" script worked, but it didn't
    work except in some trivial cases. For example, it fails in a common case
    when != -1; and for platform devices that are children
    of other devices. And of course there's the syntax issue ... only one
    module name at a time (so modprobe in a loop).

    The MODULE_ALIAS() stuff only kicks in when the driver name isn't the
    same as its module name. Normally, developers just stick to one name.

    > > 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.
    > But, I don't understand why a module would have an alias with the same
    > name as itself? What is that achieving here? Shouldn't redundancy like
    > that be eliminated?

    To repeat, I am _not_ the one who has made that proposal. I'm the one
    pointing out that all names for a module (aliases vs. what "ls" shows)
    should be treated the same ... introducing a new rule about how hotplug
    (or coldplug) must only refer to aliases promotes fragility.

    > > The $SUBJECT patch makes those legacy drivers NOT use the $MODALIAS
    > > mechanism ... you seem to be overlooking that.
    > No, I'm not overlooking that, I think it's a good thing. I'm just
    > wondering if it could be done a different way. Perhaps in the platform
    > device itself instead of the driver core code?

    Marco was overlooking it.

    I thought about moving that bit elsewhere, but three things came to mind:

    * Space-wise, there are already unused bits there, so this is free;
    but there are no such bits in platform_device.

    * Given that this is a "legacy style" issue, not all such driver
    code is (or will be) on the platform bus.

    * Hey, not all devices and busses support hotplugging, and it'd be
    worth having discussion on that. The flag is explicitly about
    the _driver_ not supporting hotplug ... a device node creation
    problem. When the _device_ is physically not hotpluggable, a
    different approach might help rid the kernel of probe()/remove()

    Given those points, I thought this was probably the best place to
    put it; at least as an initial proposal.

    Another proposal, which I dislike, is just not to have platform_bus
    do hotplug (via $MODALIAS). That'd be OK for some current embedded
    systems, since the devices get created during board startup and are
    not added/removed later, but that's exactly the sort of idiosyncratic
    restriction I've observed will invariably cause pain later on. It's
    too easy to think of counterexamples, like devices appearing when a
    board gets powered up.

    - 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-07 02:51    [W:0.025 / U:8.732 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site