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

From: Jeremy Fitzhardinge (jeremy@goop.org)
Date: Sat Apr 15 2000 - 16:01:14 EST


On 15-Apr-2000 H. Peter Anvin wrote:
> FWIW, it would be a trivial hack to make autofs capable of generating
> device nodes on demand. I have yet to see any strong use for that,
> though; emphasis here on "on demand."

The most awkward thing about adding devfs stuff to autofs stuff is
allowing non-daemon processes to create device nodes. That would change
a number of assumptions about what can happen when.

On the other hand, that leads to an interesting possibility for devfs.
Rather than using tar to save/restore the device tree, and rather than
using some VFS hacking to get to an "underlying" filesystem, why not just
pass mknod/mkdir/symlink/unlink/rmdir/chown/chmod events through to devfsd
so it can keep track of the current state of /dev in real time? Then
there's no problem saving and restoring it. And it will be just another
userfs/autofs/nfs/coda kernel<->userspace filesystem protocol.

        J

-
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:27 EST