From: David Brownell <david-b@pacbell.net>
To: Greg KH <gregkh@suse.de>
Cc: Kay Sievers <kay.sievers@vrfy.org>, "Marco d'Itri" <md@Linux.IT>,
linux-kernel@vger.kernel.org
Subject: Re: [Bulk] Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers
Date: Wed, 29 Nov 2006 17:27:31 -0800 [thread overview]
Message-ID: <200611291727.31999.david-b@pacbell.net> (raw)
In-Reply-To: <20061129230219.GA11539@suse.de>
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
next prev parent reply other threads:[~2006-11-30 1:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061122135948.GA7888@bongo.bofh.it>
[not found] ` <1164623293.3702.4.camel@pim.off.vrfy.org>
[not found] ` <20061127190315.GA28107@suse.de>
2006-11-29 22:50 ` [patch 2.6.19-rc6] fix hotplug for legacy platform drivers David Brownell
2006-11-29 23:02 ` Greg KH
2006-11-30 1:27 ` David Brownell [this message]
2006-12-01 7:04 ` [Bulk] " Greg KH
2006-12-05 2:28 ` David Brownell
2006-12-05 10:01 ` Marco d'Itri
2006-12-06 0:03 ` David Brownell
2006-12-06 6:08 ` Greg KH
2006-12-07 0:25 ` [Bulk] " David Brownell
2006-12-06 23:56 ` Marco d'Itri
2006-12-09 6:03 ` David Brownell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200611291727.31999.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=md@Linux.IT \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox