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

[Christoph Hellwig]

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.