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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <m1tyz01kcg.fsf@fess.ebiederm.org>
Date:	Fri, 18 Sep 2009 05:57:35 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Scott James Remnant <scott@...onical.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Kay Sievers <kay.sievers@...y.org>,
	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

Scott James Remnant <scott@...onical.com> writes:

>> 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?

Ultimately the way devtmpfs seems to be aimed is as a core component
that is non-optional if you use a standard user space.

My goal in reviewing the code has really been to see if I can
understand the problem devtmpfs has been trying to solve, so I could
understand if devtmpfs is a good solution.

I'm persuadable and I would have really liked to see that devtmpfs
at least comes out of the alternatives.

I want to know why for example the following document no longer applies:
http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

What has changed that makes devfs the bees knees all of a sudden.

My object to devtmpfs going in is that Greg KH and Kay seem to be
in an echo chamber and can't seem to hear when people talk about
bugs in devtmpfs.  So I am not prepared to extend Greg and Kay the
benefit of the doubt any more.

Eric

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