[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zk42tab4.fsf@xmission.com>
Date: Thu, 04 Oct 2012 10:29:51 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Kay Sievers <kay@...y.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Walls <awalls@...metrocast.net>,
Greg KH <gregkh@...uxfoundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Ming Lei <ming.lei@...onical.com>,
Lennart Poettering <lennart@...ttering.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kay Sievers <kay@...hat.com>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Michael Krufky <mkrufky@...uxtv.org>,
Ivan Kalvachev <ikalvachev@...il.com>
Subject: Re: udev breakages -
Kay Sievers <kay@...y.org> writes:
> If that works out, it would a bit like devtmpfs which turned out to be
> very simple, reliable and absolutely the right thing we could do to
> primarily mange /dev content.
ROFL.
There are still quite a few interesting cases that devtmpfs does not
even think about supporting. Cases that were reported when devtmpfs was
being reviewed.
Additionally the devtmpfs maintainership has not dealt with legitimate
concerns any better than this firmware issue has been dealt with. I
still haven't even hear a productive suggestion back on the hole
/dev/ptmx mess.
As it happens devtmpfs wound up being a userspace process that happens
to reside in the kernel and call mknod. How it makes sense two layers
of messaging and device management instead of just one I don't know.
Certainly I would not crow about that being a success of anything except
passing the buck.
There is debacle written all over the user space interface for dealing
with devices right now.
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/
Powered by blists - more mailing lists