Linux-kernel mailing list archive 2000-15,: Re: Suggested dual human/binary interface for proc/devfs

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

Christoph Hellwig (chhellwig@gmx.net)
Thu, 13 Apr 2000 18:33:18 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Bernhard Rosenkraenzer: "[PATCH] 2.3.99p6p1: irda doesn't compile"
- Previous message: Alejandro Conty: "the ide problem"

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/

- Next message: Bernhard Rosenkraenzer: "[PATCH] 2.3.99p6p1: irda doesn't compile"
- Previous message: Alejandro Conty: "the ide problem"