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

From: H. Peter Anvin (hpa@transmeta.com)
Date: Sat Apr 15 2000 - 16:03:39 EST


Jeremy Fitzhardinge wrote:
>
> 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.
>

Pretty much. It still begs the question why you need the virtual
filesystem underneath though.

        -hpa

-
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