Re: Larger dev_t

[Andrew Pimlott]

On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:
> The problems with devfs (other than kernel memory bloat, which is pretty
> much guaranteed to be much worse than the bloat a larger dev_t would
> entail) is that it needs complex auxilliary mechanisms to make
> "chmod /dev/foo" work as expected (the change to /dev/foo is to be
> permanent, without having to edit some silly config file)

The elegant solution seems obvious to me.  What we have today is two
namespaces--device major/minor, and filesystem--that are bridged by
special files.  Special files live in the filesystem namespace and
point into the major/minor namespace.  Objects in the major/minor
namespace are directly accessible only by root (ie, only root can
mknod(2)); but when accessed through special files, access control
comes from the special file.

The concept that makes this work is that the special file is a
"pointer with permissions".  To make devfs work, you want the same
thing--except a pointer into filesystem space, not major/minor
space.  Unix doesn't have this, but it would be a simple cross of
symlinks (pointer living in the filesystem and pointing into the
filesystem) and special files (pointers with permissions).

To be concrete:  You'd have a root-only (or perhaps the directories
could be a+rx--but minimal policy) hierarchy under /devices, and the
admin would populate /dev with "special symlinks" that point into
/devices, and give the appropriate permissions to users.

I have no idea whether this is feasible, but it is much more
attractive to me than devfsd, or layered mounts, or tar at
shutdown, or anything else I've heard.

Andrew