On Dec 06, David Brownell <[EMAIL PROTECTED]> wrote: > > 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) I.e. a quick hack which has never been used by any distribution. And anyway some kernel component is supposed to provide the aliases pointing from the $MODALIAS values to the drivers, so modprobe $MODALIAS would still work.
> Those scripts have supported hotplug and coldplug on several embedded boards > for some time now. Can you mention some? > 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). I am asking what is the point for a module to provide its own name in $MODALIAS. You say that not doing this would break your custom hotplug subsystem, but you still have not explained how this would happen since $MODALIAS is available only *after* the module has been loaded by something else. > 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. Who cares? It does now, and for many good reasons. -- ciao, Marco - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/