On Thursday 30 November 2006 11:04 pm, Greg KH wrote:> 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

No design is problem free, but I was just saying that any problemsin that context are because of someone needlessly fighting that design.

Like "of course you get into accidents when you drive on the wrongside of the road", or "of course zeroing /dev/kmem as root crashes".

> 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?

We don't, today. But that's the direct consequence of the change Kay haspromoted ... that is, the pushback on the $SUBJECT patch, trying to castthe issue as related to how drivers are identified, not than how they act.

It's either create such pointless aliases for quite a few drivers *OR* breakwhat is currently _working_ hotplug on many busses ... nontrivial regression,requiring a lot of work to resolve that would mean deployment delays on the(usual/optimistic) order of 12 months or so for tool updates.

In reality, "modalias" is the misnomer ... it's the kind of implementationdetail that's bad to put into an interfaces. The role of that informationis "driver identifier". Which for many busses is the module name.

For some expansion busses, like PCI and USB, the identifier supportssome bus-specific wildcard match rules. Those busses were architectedaround such driver match rules. And modprobe was modified to understandthose wildcard rules; and kbuild was modified to generate module aliasesthat hotplug could feed to "modprobe". Fancy busses, fancy infrastructure;it took a long time to get to the point where /sbin/hotplug can be assimple as "modprobe $MODALIAS" (if needed!) plus "udevsend".

Busses like that are the exception though. Most don't have any kindof dynamic identification/enumeration infrastructure, or multi-vendordriver match algorithm ... those have both design and implementationcosts, which are not always justifiable. (Once you know the chip/board,you know every device on it; so there's no point in adding any supportfor auto-enumeration. There are also power management issues, sincedevices' interface clocks likely default to "off". Linux must explicitlyenable those clocks, defeating the purpose of auto-enumeration...)

So the best that most busses can have is a Linux-specific driver ID;although if you were judging by PC expansion busses, you might thinkotherwise. To Linux, "platform_bus" covers many dozens of differenthardware implementations. On one SOC series, I can easily count adozen such busses ... sometimes just within one chip.

And in the context of platform_device and platform_driver, the driverID has always been the driver name ... which in all but a few casesis also the module name. There's been a trivial workaround for thosefew cases: MODULE_ALIAS(driver_name).

> > > 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?

The new rule that's being promoted, with effect of breaking hotplugand coldplug for platform drivers. (And SPI drivers, and any otherbus that doesn't want to create needless complexity by requiringupdates to module-init-tools and kbuild.) And some cases of KMOD.

That is, the new rule that requires the driver identifier never to bethe same as its module name ... and (a different rule?) requiring thatthe driver identifer always be an alias, since (courtesy of the otherrule) the identifier couldn't be the module name. The one requiringthat $MODALIAS become an actual alias, instead of a driver ID.

(You can tell those are new rules by the fact that applying themwould immediately break hotplug for some busses. As well as KMODin various cases. And that they literally have nothing to do withthe root cause of the problem addressed by $SUBJECT patch.)

> KMOD worked off of char device aliases for the most part.

Not always. I did a grep. Things will (needlessly) break if anyonestarts to apply those new rules. Platform bus is not the only example.Notice how ata_probe() gets "ide-cd.ko", etc.

> > 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?

The pushback on $SUBJECT patch. Which amounts to wanting to break hotplugfor several busses, unless someone (NOT the folk promoting the breakage!)updates (a) every driver on those busses, to add some new annotations forhotplug, (b) kbuild, to handle those annotations so that (c) some new andas-yet-undesigned/undeployed module-init-tool modifications can return thosesystems back to **TODAY'S LEVEL OF FUNCTIONALITY** ... it'd likely be sometimelate next year before very many systems get back to working as well as theywork right now.

Just because of someone wanting to create a _new kernel policy_ about driveridentification ... requiring it to only be done using aliases, making realnames become, in some sense, second class citizens. (Which is a bizarre notionon so many levels I have a hard time starting to describe them all...)

- 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.

The only _problem_ ever identified to me is the one where "modprobe i82365"on systems without that hardware could make trouble. That should be fixedby $SUBJECT patch; a few dozen other ISA-era drivers have the same issue.

The _confusion_ is all this noise about wanting to change the rules associatedwith module naming instead ... while still letting non-hotpluggable drivers tryto hotplug. Most of it could have been avoided by not dodging the "legacy driver"issue each time it was highlighted, or the way that half-formed rule changeproposal would cause significant regressions.