Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

[Kay Sievers]

On Sat, May 2, 2009 at 03:24, Brian Swetland <swetland@xxxxxxxxxx> wrote:
> On Thu, Apr 30, 2009 at 11:55 PM, Greg KH <greg@xxxxxxxxx> wrote:
>> On Thu, Apr 30, 2009 at 11:43:12PM -0700, Andrew Morton wrote:
>>> On Thu, 30 Apr 2009 23:17:01 -0700 Greg KH <greg@xxxxxxxxx> wrote:
>>> > On Thu, Apr 30, 2009 at 10:29:00PM -0700, Andrew Morton wrote:
>>> >
>>> > Well, devfs "done right" with hopefully none of the vfs problems the
>>> > last devfs had. :)
>>>
>>> I think Adam Richter's devfs rewrite (which, iirc, was tmpfs-based)
>>> would have fixed up these things. ÂBut it was never quite completed and
>>> came when minds were already made up.
>>>
>>> I don't understand why we need devfs2, really. ÂWhat problems are
>>> people having with teh existing design?
>>
>> Boot speed, boot speed, boot speed.
>>
>> Oh, and reduction in complexity in init scripts, and saving embedded
>> systems a lot of effort to implement a dynamic /dev properly (have you
>> _seen_ what Android does to keep from having to ship udev? ÂIt's
>> horrible...)
>
> It's always struck me as odd that sysfs couldn't provide device node
> access, given that there's already an entity exposed for everything
> (or nearly everything).

You really want to be able to run grep-like stuff in sysfs, which
would do horrible things with device nodes. Also it does not support
extended attributes, not access control lists, ..., all stuff we need
for device nodes. You also want userspace to have control over device
nodes, and possibly mangle them, regardless what the kernel exports,
that's why it's a tmpfs and not part of sysfs.

> It seems weird to have to have an agent in
> userspace to create another hierarchy in addition to what the kernel
> already maintains.

Well, until just recently, there was no sane definition how device
nodes are names and layouted, every system did it differently, some
even tried to keep the totally useless devfs naming scheme alive. Now
that we managed to define a common default setup, which almost
everybody ships it, it makes it possible to add the few needed rules.

> I guess the really tricky bit is how to deal with
> permissions/ownership sanely.

Simple permissions would be possible without too much hassle, but uid
gid ownership, I can't see how the kernel could do that.

> I suspect there's no easy way to do
> something that "just works" for even the majority of userspace
> environments.

It will work just fine for root environments, what's missing without
userspace support is if you need to grant specific users access to
devices.

> Most of the ugly in the microudev thing in our init
> comes from having to do something about permissions.
>
> I would love to have a way for the kernel to do something like devfs
> (it'd let me kill some ugly userspace code on my side)....

How are permissions defined in your environment? What's the set of
permissions you need to apply?

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/