Re: [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 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/
Re: [Bulk] Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers
On Wed, Nov 29, 2006 at 05:27:31PM -0800, David Brownell wrote: > On Wednesday 29 November 2006 3:02 pm, Greg KH wrote: > > > > > > Here's my fix. ... > > > ... I audited all the drivers using the relevant APIs, and I can't > > > see many (if any!) folk hitting problems from this. > > > > But this still can cause the problem that your 'modalias' file in sysfs > > contains exactly the same name as the module itself, right? > > Not a problem if folk stick to the original design. Hotplug will at > most "modprobe $MODALIAS" (iff the device needs a driver) before doing > a udevsend ... and only coldplug uses "modprobe $(cat modalias)". I'm not saying that the design does not have problems, but having a modalias with no real alias does not make much sense to me. > I could update the patch so that attribute turns into a null string, > but that would have a **negative effect** since it would break coldplug > for all the platform init code which doesn't use platform_add_devices() > or maybe platform_device_register(). Ok, I'm being thick here, but why do we need a modalias with the same name as the module? > > That's not good, it should be an alias, not the "real name". > > Well, adding unjustified complexity _after the fact_ isn't good either, > and that's what I see going on here. > > How many years has KMOD been around? It's worked just fine without that > sort of bizarre (and un-needed) rule. What rule? KMOD worked off of char device aliases for the most part. > Aliases were provided just to give *additional* names to modules ... > not to make one needlessly "special". Kernel request_module() calls > make no distinction between which type of name they use ... and when > the filesystem name changes, they still work when the old name is > properly aliased. > > That whole "give a module an alias of itself" model just seems ludicrous > to me. We _know_ that "A" means "A", so there's no point in aliasing it > as itself. I thought that was my point here :) So what's the issue? > ... plus it's a distraction from the real problem, namely that certain > "legacy" drivers, primarily stuffed onto the "platform" bus, can't ever > hotplug. (While normal platform drivers do so just fine, without needing > strange rules to make some names "more equal than others".) But does this solve that problem? ugh, I'm confused... greg k-h - 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/
Re: [Bulk] Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers
On Wednesday 29 November 2006 3:02 pm, Greg KH wrote: > > > > Here's my fix. ... > > ... I audited all the drivers using the relevant APIs, and I can't > > see many (if any!) folk hitting problems from this. > > But this still can cause the problem that your 'modalias' file in sysfs > contains exactly the same name as the module itself, right? Not a problem if folk stick to the original design. Hotplug will at most "modprobe $MODALIAS" (iff the device needs a driver) before doing a udevsend ... and only coldplug uses "modprobe $(cat modalias)". The two were provided to address distinct problems. And the issue that was described to me was _only_ relevant on the hotplug paths; coldplug scripts, using /sys/devices/.../modalias files, see no problems. I could update the patch so that attribute turns into a null string, but that would have a **negative effect** since it would break coldplug for all the platform init code which doesn't use platform_add_devices() or maybe platform_device_register(). > That's not good, it should be an alias, not the "real name". Well, adding unjustified complexity _after the fact_ isn't good either, and that's what I see going on here. How many years has KMOD been around? It's worked just fine without that sort of bizarre (and un-needed) rule. Aliases were provided just to give *additional* names to modules ... not to make one needlessly "special". Kernel request_module() calls make no distinction between which type of name they use ... and when the filesystem name changes, they still work when the old name is properly aliased. That whole "give a module an alias of itself" model just seems ludicrous to me. We _know_ that "A" means "A", so there's no point in aliasing it as itself. ... plus it's a distraction from the real problem, namely that certain "legacy" drivers, primarily stuffed onto the "platform" bus, can't ever hotplug. (While normal platform drivers do so just fine, without needing strange rules to make some names "more equal than others".) > That will ensure that userspace tools do not get confused, I don't observe any confusion on my systems. Platform device hotplug works just fine. Udev creates their /dev nodes. If there are some tools getting confused, that seems best characterized as tool bugs. - 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/
