Re: [patch 00/13] devtmpfs patches

From: Kay Sievers
Date: Sat May 09 2009 - 12:46:44 EST


On Sat, May 9, 2009 at 17:22, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
> On Sat, 9 May 2009 08:08:53 -0700
> Greg KH <gregkh@xxxxxxx> wrote:
>
>> > Well, guess you meant the opposite ;-)
>>
>> Heh, yes, sorry about that. ÂIt makes booting faster :)
>
> .. and I don't buy that.

Don't buy, just try it - and you will see. :)

We must mount a tmpfs at some point during bootup, wherever you do
that, in initramfs or the real root. Doing that, there will obviously
be a point, where /dev is empty, exactly at that time you can not do
anything else, which is not very tightly controlled, you can not just
start stuff in parallel during that time. Devtmpfs gets rid of that
limitation, and offers you to do things without waiting for a hard
checkpoint. It's obviously the fastest one can do, like number can
show. There can be no faster alternatives for this implemented in
userspace.

> The only argument I've heard is "oh but it's hard". No it's not.
> The other argument is "but for more partitions we get other device
> numbers"... you know what, that's easy to fix. Just make the 32 bit dev
> number consistent. Few lines of code I bet, and it is benefit for
> everyone to do that....

And all the other subsystems. You can't even trust a single static
node for rtc devices, and so on ... Converting all of that stuff in
the kernel is just not a real option. Static device nodes a bad hack,
and distros do not do that today, and can for reasons of correctness
and reliability, not start doing that.

> Beyond that... this is not needed... but at least call it "devfs".. for
> what it is.
>
> (and yes there is very obvious irony)

No problem, it's just a random name we've choosen, that even contains
all of "devfs". :) I just liked to express, that one can do whatever
one wants to do with the nodes from userspace, just like we can today.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/