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

[ebiederm@xmission.com (Eric W. Biederman)]

Scott James Remnant <scott@canonical.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