linux-kernel - Re: [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1253213956.4718.18.camel@quest>
Date:	Thu, 17 Sep 2009 19:59:16 +0100
From:	Scott James Remnant <scott@...onical.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Kay Sievers <kay.sievers@...y.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartmann <greg@...ah.com>
Subject: Re: [PATCH] Remove broken by design and by implementation devtmpfs
 maintenance disaster

On Thu, 2009-09-17 at 19:47 +0200, Arjan van de Ven wrote:

> > I don't really see the issue here.  If Arjan doesn't want to use
> > devtmpfs for Moblin, he doesn't have to.
> 
> my biggest objection was to the use of boot time as argument.
> That was and still is deceiving and false. There may be other arguments
> for devfs, but I'm not going to get in the middle of those. But boot
> time isn't it.
> 
Right, I don't disagree.

For some distributions devtmpfs allows them to do things without running
udev early; we long ago restructured Ubuntu so that udev is one of the
first things we run, therefore don't have that particular problem.

From my POV devtmpfs is useful because it means we can do away with udev
entirely in certain situations, especially the installer and probably
our initramfs when we need one too.

The "statically make /dev from /sys" tools don't help, because /dev
needs to be kept up to date.  And udev is too heavy, or the increased
maintenance of having a special installer udev is too annoying, etc.

devtmpfs happens to be a neat solution to that problem.

> I do share frustration with Eric on how Kay and Greg have handled this.
> It really felt like a combination of bullying, ignoring any contrarian
> argument and just ramming stuff down. Not at all unlike the original
> devfs fiasco. It has left me with a pretty bad taste in my mouth and
> am pretty disappointed; I expected better.
> 
I'm not a kernel developer, I'm a plumbing developer, but from my
outside perspective it seems like the contrary arguments have had a bit
of an agenda as well and have taken a "must not go in at any cost"
attitude.

That I find odd.

It's not as if this is critical path, or going in at the expense of
other functionality or code.  It's just another useful option for people
who can find a use for it.

Is that really such a tragedy to have?

Anyway, I should start packing and stuff.  See you next week!

Scott
-- 
Scott James Remnant
scott@...onical.com

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)