linux-kernel - Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

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:	Wed, 5 Aug 2009 19:20:37 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>,
	Jan Blunck <jblunck@...e.de>, gregkh@...e.de,
	Harald Hoyer <harald@...hat.com>,
	Scott James Remnant <scott@...ntu.com>
Subject: Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based
 /dev

On Wed, 5 Aug 2009 10:15:13 -0700
Greg KH <greg@...ah.com> wrote:

> Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.

You seem to have reposted it rather than anyone addressing any of the
complaints people made about ?

To quote Christoph

> What tree did you find with devtmpfs in it?  It was pretty clearly
> rejected when it came up.

and Arjan (who is doing about the fastest Linux boot anyone has and has
better data than anyone else)

> so just to state the obvious: this code is not needed to boot fast.
> It is mostly a workaround for having a bad initrd; if you don't use an
> initrd, or if you use an initrd that's made with the right device nodes
> in it already, you really just don't need this.

> I would much rather that you just fix your initrd... than to put this
> sort of thing into the kernel....

plus 

> Eric has shown that just making the nodes is 0.06 seconds with todays
> sysfs interface, and there is room for improvement,

and Erik Biederman

>> option for us. And still, nobody will be forced
>> to use it, it's entirely optional. For our systems, we decided to do
>> it that way, and we ship it already in the distro, and if there are no
>> substantial problems coming up, which we don't expect, we will
>> continue using it.  

> Yes but you are asking all of us to maintain it.  Forever in perpetuity.
> A better case needs to be made than you have already shipped the code.

Also can you confirm the SELinux issues raised by Stephen Smalley and
David Quigley were fixed and resolved.

Alan
--
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/