[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <m1fxfbuyv7.fsf@fess.ebiederm.org>
Date: Mon, 11 May 2009 14:13:32 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Kay Sievers <kay.sievers@...y.org>
Cc: Arjan van de Ven <arjan@...radead.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Peter Zijlstra <peterz@...radead.org>,
Greg KH <gregkh@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Fabio Comolli <fabio.comolli@...il.com>,
Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/13] devtmpfs patches
Kay Sievers <kay.sievers@...y.org> writes:
> On Mon, May 11, 2009 at 18:40, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> The goal for kernel compile options is that they do not affect the
>> kernels behavior. The behavior in devmtmpfs clearly does not match
>> that rule. The kernel acts very different with it compiled in
>> and with it not compiled in. So that section of the code deserves.
>
> It's the same as with any other option, like the ones that enable
> dynamic minors.
No it's not.
The practical goal is that a distribution can enable essentially every feature
in the kernel and not be forced to use one.
The most similar example I can think of is the dhcp client in the kernel.
Even when compiled in only if you enable it on the command line (aka ip=dhcp)
does it enable and attempt to network boot.
Mouting on /dev might be sane if it was enabled by a kernel command line option.
By default it is wrong.
Dynamic minors is right on that hairy edge. I'm puzzled know why we
can't have the first N devices use the static assignment and the rest
of the devices use the dynamic minors.
Eric
--
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