Re: (Semi-random) thoughts on device tree structure and devfs

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Tue, 9 Mar 2010 21:59:23 +0000 (UTC)
christos%astron.com@localhost (Christos Zoulas) wrote:

> In article 
> <70f62c5e1003091104l20b98c5ex66842f01e6f17a2d%mail.gmail.com@localhost>,
> Masao Uebayashi  <uebayasi%gmail.com@localhost> wrote:
> >> Wow, that sucks. ÂNot being able to change permissions (and less 
> >> importantly,
> >> mv or rm the device files) would definitely be a problem.
> >
> >Could you show me use cases how it sucks?  I need more use cases.
> 
> - I want to present a subset of devices to a chrooted devfs.
> - I want to give a different set of permissions than the default.
> - I want to be able to call a device by a different (symbolic name) without
>   using symlinks.
> - I want to prevent access to the device completely by not providing a device
>   node.
> - I want to preserve those changes across boots.
> - I want to be able to move all my disk devices to a subdirectory.

I had to deal with every of those scenarios, and never could stand
existing devfs implementations on my systems; I however previously
participated to a thread about devfs with ideas and suggestions for a
possibly less broken pipe-dream implementation, but it simply tought me
how complex a decent implementation would have to be, IMO.

I however like the idea of simply having additional symlinks
automatically be created to redirect unique names to the actual
existing nodes (possibly the best implementation of this would be done
via a virtual fs controled by the kernel, mounted under /dev/uuid/ or
the like?).  This wouldn't affect the target device node permissions,
at least, and might solve most of the hotplug issues for users who
need automount or can't track dmesg to then manually mount a device...

Of course, if a removable device is supposed to move around a few sb*
nodes depending on when/where it's plugged, then at least the admin can
set permissions for all devices in that class, additionally to the
permissions for the fs in /etc/fstab, just as traditionally.
-- 
Matt