Re: Suggested dual human/binary interface for proc/devfs

From: Kjetil Torgrim Homme (kjetilho@ifi.uio.no)
Date: Thu Apr 13 2000 - 14:40:29 EST


[Linus Torvalds]

> Wrong. If you have to have backing store, THEN it is broken. That
> shows that devfs doesn't actually buy you anything, and playing
> with a virtual filesystem is not worth it. Because there are no
> advantages.

Agreed. I think the tar "solution" gives people the wrong idea. A
backing store may be seen as superior to tar, since it is less error
prone, but it is not a good solution to the _real_ problem. One of
the motivations for devfs was to handle hotplug devices without the
need for a preconfigured /dev. As has been pointed out, a backing
store _is_ that preconfigured /dev. We have only obsoleted MAKEDEV.

To make devfs really useful the permissions need to be set on a higher
level, algorithmically and dynamically. That is, a user space device
manager where you can specify _general_ rules like "members of the
backup filegroup shall have read access to all storage devices". Or
"the currently logged in user shall have full access to all removable
media" -- enumerating the Zip, the floppy, the CDROM etc. shouldn't be
necessary (but the admin might want to). The pam_console module tries
to address these issues from the viewpoint "the user changes". The
truly general solution needs an enhanced devfsd(?) which handles
hardware changes as well, even devices unforeseen by the sysadmin.

Some work has to be done in the kernel, though -- the drivers need to
supply enough information for the device manager to classify its
resources and apply the rule sets.

Kjetil T.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:22 EST