[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=jft-j+2Y_dez_gJSrHEkuKSwKq8PbPZxvuHqk@mail.gmail.com>
Date: Wed, 8 Sep 2010 17:19:25 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Olof Johansson <olof@...om.net>
Cc: Lei Wen <adrian.wenl@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
Mandeep Baines <msb@...omium.org>
Subject: Re: [PATCH v3] mmc: add config and runtime option for number of
mmcblk minors
On Wed, Sep 8, 2010 at 16:57, Olof Johansson <olof@...om.net> wrote:
> On Wed, Sep 08, 2010 at 10:25:58PM +0800, Lei Wen wrote:
>
>> The patch's purpose is good. As modern sd&mmc is used to host the file
>> system, the 8 partition limitation is becoming a kind of bottleneck...
>> But why not just add GENHD_FL_EXT_DEVT flag to allow mmc use extended
>> partition numbers?
>
> No need to quote the whole patch next time. :)
>
> Given that MMC is sometimes used in deeply embedded environments where
> udev might not be running to take care of dynamic device numbering,
> I chose to stay with a static layout.
>
> I could be convinced otherwise though. It would cause some additional
> hassles for me since we start udev lateish during boot and have a
> prepopulated /dev before that, but that can be dealt with.
I think the extended number are only used for stuff larger than the static 8?
Apart from that, you can not reliably or securely use a static /dev
these days, you never know which device you talk to, because the
kernel has far too many dynamically assigned numbers. For that reason,
most embedded setups use the busybox hack to populate /dev. Recent
kernels have a devfs again, and there is no reason today to continue
any static /dev experiments -- unless someone is going over the entire
tree and fixes all the dynamic assignments, which is unlikely to
happen ever.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists