From: Pierre Ossman <drzeus-mmc@drzeus.cx>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Andy Whitcroft <apw@canonical.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mmc: add MODALIAS linkage for MMC/SD devices
Date: Tue, 27 Jan 2009 20:14:06 +0100 [thread overview]
Message-ID: <20090127201406.27c8592f@mjolnir.drzeus.cx> (raw)
In-Reply-To: <ac3eb2510901250800g40dd31d8q35e626413f2853a1@mail.gmail.com>
On Sun, 25 Jan 2009 17:00:11 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sun, Jan 25, 2009 at 16:48, Pierre Ossman <drzeus-mmc@drzeus.cx> wrote:
> >
> > My point was to have the kernel explicitly ask for the module it wants
> > as there is no decent device to driver mapping scheme.
>
> Yep, which is what we do not want. Aliases are "aliases", and not
> "module names". We need to add a matching alias to the module then.
> Direct module names can not properly defined/blacklisted in userspace,
> and we would need to work around that.
> Every modalias should be
> "<subsystem>:<whatever-name-fits-for-the-subsystem>" to plug properly
> into the autoloading infrastructure. We rather have no modalias at
> all, then a kernel module name there.
>
The thing is that asking for a module is the only thing we can do here.
We can dress it up and give it some special coding to not cause
problems, but the code will always be "ask userspace to load
mmc_block", even if we replace "mmc_block" with "mmc:foobargazonk".
Given that, do you have any preferences for a solution? If we cannot
simply have "mmc_block", then I'm leaning to "mmc:block" for now. The
contents of the aliases is just an opaque string as far as userspace is
concerned, right?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
next prev parent reply other threads:[~2009-01-27 19:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-06 18:56 Andy Whitcroft
2009-01-12 15:05 ` Pierre Ossman
2009-01-15 15:00 ` Andy Whitcroft
2009-01-24 17:56 ` Pierre Ossman
2009-01-24 23:45 ` Kay Sievers
2009-01-25 15:48 ` Pierre Ossman
2009-01-25 16:00 ` Kay Sievers
2009-01-26 9:35 ` Andy Whitcroft
2009-01-27 12:12 ` Andy Whitcroft
2009-01-27 19:14 ` Pierre Ossman [this message]
2009-01-27 19:26 ` Kay Sievers
2009-01-28 15:06 ` Andy Whitcroft
2009-01-28 19:58 ` Pierre Ossman
[not found] <20090218205654.05896ece@mjolnir.ossman.eu>
2009-02-23 12:38 ` Andy Whitcroft
2009-03-02 21:10 ` Pierre Ossman
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=20090127201406.27c8592f@mjolnir.drzeus.cx \
--to=drzeus-mmc@drzeus.cx \
--cc=apw@canonical.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
Powered by JetHome