linux-kernel - Re: [patch 00/13] devtmpfs patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 9 May 2009 18:46:10 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Greg KH <gregkh@...e.de>, Fabio Comolli <fabio.comolli@...il.com>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/13] devtmpfs patches

On Sat, May 9, 2009 at 17:22, Arjan van de Ven <arjan@...radead.org> wrote:
> On Sat, 9 May 2009 08:08:53 -0700
> Greg KH <gregkh@...e.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/