From: Kay Sievers <kay.sievers@vrfy.org>
To: Adam Belay <ambx1@neo.rr.com>, Andrew Morton <akpm@osdl.org>,
Pierre Ossman <drzeus-list@drzeus.cx>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [PNP] 'modalias' sysfs export
Date: Sun, 12 Mar 2006 06:09:55 +0100 [thread overview]
Message-ID: <20060312050955.GA5676@vrfy.org> (raw)
In-Reply-To: <20060312042957.GA14157@neo.rr.com>
On Sat, Mar 11, 2006 at 11:29:57PM -0500, Adam Belay wrote:
> On Sat, Mar 11, 2006 at 05:38:47PM -0800, Andrew Morton wrote:
> > Pierre Ossman <drzeus-list@drzeus.cx> wrote:
> > >
> > > Here is a patch for doing multi line modalias for PNP devices. This will
> > > break udev, so that needs to be updated first.
> > >
> > > I had a longer look at the card part and it seems that module aliases
> > > cannot be reliably used for it. Not without restructuring the system at
> > > least. The possible combinations explode when you notice that the driver
> > > ids needs to be just at subset of the card, without any ordering.
> > >
> > > If I got my calculations right, a PNP card would have to have roughly
> > > 2^(2n) aliases, where n is the number of device ids. So right now, I
> > > lean towards only adding modalias support for the non-card part of the
> > > PNP layer.
> > >
> > > Andrew, do you want a fix for the patch in -mm or can you remove the
> > > part of it that modifies drivers/pnp/card.c by yourself?
> >
> > I assume you mean that the drivers/pnp/card.c patch of
> > pnp-modalias-sysfs-export.patch needs to be removed and this patch applies
> > on top of the result.
> >
> > But I don't want to break udev.
>
> I think supporting multiple IDs per node is a reasonable expectation to
> have from udev (even for subsystems beyond PnP). Kay, would this be
> difficult to add?
Udev does not care about $MODALIAS at all about the string, it just
runs configured programs when a device is added. It's unlikely,
that we will ever need/have a built-in MODALIAS handling in udev.
Distros handle that all differently, most just do "modprobe $MODALIAS"
with the device event.
> However, I'm a little confused as to why we're exporting these "modalias"
> strings from a kernel interface in the first place. Wouldn't it be better
> from an abstraction barrier standpoint to have userspace generate such
> strings from information it gathered through bus-specific interfaces?
Well, the modalias match strings are native part of the kernel modules, so
it is just convenient to have the kernel to create the modalias to match
against these strings too. Userspace and modprobe usually doesn't care about
the actual content of the strings, as both come from the kernel and just need
to match each other. In theory, there is no need to keep userspace updated,
if a new bus is added, or the format is changed, which is nice.
> As
> can be seen from this example, when the modalias (or essentially a device
> identification key) is imposed at the kernel level driver model interface,
> one has to make policy decisions (e.g. what legacy features such as isapnp
> are we going to only psuedo-support).
What "policy"? We only need a way to export the multiple matches in a
sane way and using a multiline value is not really nice, especially when
added to the environment.
Thanks,
Kay
next prev parent reply other threads:[~2006-03-12 5:09 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 21:40 [PATCH] [PNP] 'modalias' sysfs export Pierre Ossman
2006-03-01 19:45 ` Kay Sievers
2006-03-02 8:39 ` Pierre Ossman
2006-03-02 16:58 ` Kay Sievers
2006-03-03 11:52 ` Pierre Ossman
2006-03-11 16:05 ` Pierre Ossman
2006-03-11 16:15 ` Arjan van de Ven
2006-03-11 16:21 ` Pierre Ossman
2006-03-12 1:38 ` Andrew Morton
2006-03-12 4:05 ` Kay Sievers
2006-03-12 4:29 ` Adam Belay
2006-03-12 5:09 ` Kay Sievers [this message]
2006-03-12 6:01 ` Adam Belay
2006-03-12 11:17 ` Pierre Ossman
2006-03-12 11:33 ` Matthieu CASTET
2006-03-12 17:23 ` Kay Sievers
2006-03-12 22:55 ` Andrew Morton
2006-03-13 4:14 ` Kay Sievers
2006-03-13 6:02 ` Adam Belay
2006-03-13 6:21 ` Kay Sievers
2006-03-13 7:04 ` Adam Belay
2006-03-13 7:26 ` Adam Belay
2006-03-13 7:36 ` Kay Sievers
2006-03-14 1:25 ` Adam Belay
2006-03-13 16:57 ` Bill Nottingham
2006-03-13 19:24 ` Kay Sievers
2006-03-13 22:26 ` Bill Nottingham
2006-03-14 12:29 ` Sergey Vlasov
2006-03-14 12:47 ` Pierre Ossman
2006-03-14 15:00 ` Sergey Vlasov
2006-05-09 17:41 ` Pozsar Balazs
2006-05-12 11:09 ` Kay Sievers
-- strict thread matches above, loose matches on Subject: below --
2006-03-11 17:07 Andrey Borzenkov
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=20060312050955.GA5676@vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=akpm@osdl.org \
--cc=ambx1@neo.rr.com \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
/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