> > 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 platform_device.id != -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() infrastructure. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
