Messages in this thread |  | | | From | Kay Sievers <> | | Date | Sat, 9 May 2009 18:46:10 +0200 | | Subject | Re: [patch 00/13] devtmpfs patches |
| |
On Sat, May 9, 2009 at 17:22, Arjan van de Ven <arjan@infradead.org> wrote: > On Sat, 9 May 2009 08:08:53 -0700 > Greg KH <gregkh@suse.de> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |