On Tue, 9 Mar 2010 21:59:23 +0000 (UTC) chris...@astron.com (Christos Zoulas) wrote:
> In article <70f62c5e1003091104l20b98c5ex66842f01e6f17...@mail.gmail.com>, > Masao Uebayashi <uebay...@gmail.com> 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
