On Sun, Mar 12, 2006 at 06:09:55AM +0100, Kay Sievers wrote:
> 259-0000
>
> 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 <[email protected]> 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.
Alright, so it would seem changing to multiple line MODALIAS values could be
potentially inconvenient for the current conventions. Therefore, this sort of
change probably shouldn't be made for PnP. However, I think pcmcia and acpi
will eventually have similar issues.
>
> > 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.
I appreciate the explanation. I guess I've always favored a more
userspace-centric driver matching mechanism than our current system. There
are some cases where multiple drivers exist and the user might want to select
a specific driver for each device instance, and I think we're very limited in
these situations because of the module level granularity of driver matching.
In any case, a native part of kernel modules is not necessarily also native to
the kernel itself. In this case, as I understand it, modalias strings are a
sort of metadata embedded in the module binary that's not necessarily referenced
by the kernel. A userspace script could rather easily read bus-specific vendor
and device ID components from sysfs and generate a string compatible with this
format.
Regards,
Adam
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
