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

From: Christoph Hellwig (chhellwig@gmx.net)
Date: Thu Apr 13 2000 - 11:33:18 EST


On Thu, Apr 13, 2000 at 12:21:09PM -0400, Alexander Viro wrote:
>
> That's fine. I think that devfs architecture is a nightmare (sorry,
> Richard), but yes, autofs is a part of the _right_ picture. Remember how
> Plan 9 does devices? Each driver uses generic code to define a filesystem
> (small tree) and you union-mount it on /dev or where the heck you want it
> to be. Make autofs a bit more generic (teach it to mount on /foo upon
> access to /foo/bar) and teach the userland part to run script upon
> (u)mount. That's it. No need to put that code into devfs - we'ld better
> teach already existing thing (autofs) to deal with that stuff (and that
> stuff only).

In my opinion the best idea would be:
        - some device (/dev/root (needs to be impmented ...)
          /dev/console, etc ...) directly in /dev
        - everything othe has it's on fs (idedevfs, scsidevfs, etc ...)
        - a /proc ( or /sys ...) file that is a kernel-generated automounter map
          e.g. /proc/auto.dev, that contains entry entrys for all fs'es.
          so you haave uidedevfs on /dev/ide
        - a daemon that makes compatibility symlinks (like devfsd)
        - yet another fs, that's union-mounted on /dev and looks up
          devices for existing nodes

Christoph

-- 
Always remember that you are unique.  Just like everyone else.

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