Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754696AbZA1PGy (ORCPT ); Wed, 28 Jan 2009 10:06:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751688AbZA1PGn (ORCPT ); Wed, 28 Jan 2009 10:06:43 -0500 Received: from adelie.canonical.com ([91.189.90.139]:37078 "EHLO adelie.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751665AbZA1PGn (ORCPT ); Wed, 28 Jan 2009 10:06:43 -0500 Date: Wed, 28 Jan 2009 15:06:39 +0000 From: Andy Whitcroft To: Kay Sievers Cc: Pierre Ossman , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] mmc: add MODALIAS linkage for MMC/SD devices Message-ID: <20090128150639.GA31473@shadowen.org> References: <1231268198-12556-1-git-send-email-apw@canonical.com> <20090112160519.3ba21848@mjolnir.drzeus.cx> <20090115150003.GB6896@shadowen.org> <20090124185612.5afddbb0@mjolnir.drzeus.cx> <20090125164858.6b281c6c@mjolnir.drzeus.cx> <20090127201406.27c8592f@mjolnir.drzeus.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2660 Lines: 55 On Tue, Jan 27, 2009 at 08:26:26PM +0100, Kay Sievers wrote: > On Tue, Jan 27, 2009 at 20:14, Pierre Ossman wrote: > > On Sun, 25 Jan 2009 17:00:11 +0100 > > Kay Sievers wrote: > > > >> On Sun, Jan 25, 2009 at 16:48, Pierre Ossman 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 > >> ":" 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? > > Right, it does not matter, we just need to be able to fnmatch() > modalias and the string in the module. > > We prefer every modalias to be prefixed with the subsystem, to be able > to hook userspace configs into the alias processing. The string itself > is completely up to the subsystem to decide whatever fits. If there > could ever be several types of strings per susbsystem, it is usual to > prefix the string with some character, but some subsystems know that > this is not needed, and just put a plain single string there. As the contents as opaque we can put whatever we want after the mmc:, the last patch I did simply used the mmc type string as a key in case it were useful. Right now it is as we do only load the block for the SD and MMC cases. But later it would be for all once the SDIO card support, supports memory. So asre we happy with the last textual patch or should I refactor back to mmc:block. -apw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/