[lkml]   [2001]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Larger dev_t
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:17    [W:0.186 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site