public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: ambx1@neo.rr.com, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [PNP] 'modalias' sysfs export
Date: Thu, 02 Mar 2006 09:39:03 +0100	[thread overview]
Message-ID: <4406AF27.9040700@drzeus.cx> (raw)
In-Reply-To: <20060301194532.GB25907@vrfy.org>

Kay Sievers wrote:
> On Mon, Feb 27, 2006 at 10:40:19PM +0100, Pierre Ossman wrote:
>> User space hardware detection need the 'modalias' attributes in the
>> sysfs tree. This patch adds support to the PNP bus.
> 
>> +
>> +	/* FIXME: modalias can only do one alias */
>> +	return sprintf(buf, "pnp:c%s\n", pos->id);
> 
> Without the FIXME actually "fixed", this does not make sense. You want to
> match always on _all_ aliases. In most cases where you have more than
> one, the first one is the vendor specific one which isn't interesting at
> all on Linux. If you have more than one entry usually the second one is the
> one you are looking for.
> 
> So eighter we find a way to encode _all_ id's in one modalias string which can
> be matched by a wildcard or keep the current solution which iterates over the
> sysfs "id" file and calls modprobe for every entry.
> 

That's a bit harsh. Although the FIXME is a downer, this patch is a
strict addition of functionality, not removal. It solves a real problem
for me, and it does so without removing any functionality for anyone
else. The fact is that most PNP devices do not have multiple id:s (at
least the ACPI variant which is the most common in todays machines), so
the problem is not near as big as you make it out to be.

That said, I agree that it would be desirable to fix this. First of all
we would need to synchronise this with userspace. Currently I guess that
means udev. Allowing 'modalias' to contain multiple lines should be a
simple enough solution (provided we don't fill the available buffer space).

The PNP cards are also a bit of a problem, but this isn't something new.
When matching a device to a driver, the card ID must match and also all
device ID:s. The problem is that the device ID:s are sets, not lists.
I.e. we compare the unordered contents of the two, with no regard to
ordering.

Rgds
Pierre


  reply	other threads:[~2006-03-02  8:39 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 [this message]
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
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=4406AF27.9040700@drzeus.cx \
    --to=drzeus-list@drzeus.cx \
    --cc=akpm@osdl.org \
    --cc=ambx1@neo.rr.com \
    --cc=kay.sievers@vrfy.org \
    --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