> > With a "good implementation"[TM] why not ?  Think of a procfs
> > that will compile both for kernel and userland, where the userland
> > version operates on a coredump.

Or, say, a libkvm that is shared between the procfs implementation and the
kmem-aware versions of popular kernel-crawling utilities such as ps?

I personally am annoyed that after decades of evolution, we still have lots
of common situations where people are expected to depend on the output format
of programs like ls, ps, and so on. How do I get the target of a symlink from
a shell script? Suppose that name has a space in it. bzzt, chalk one up to the
BUGS section.

> I like the idea of the plan 9 abstraction myself. I would prefer to
> get rid of the non-file namespaces and non-file access methods for the 
> kernel. Unfortunately, practicality interferes here.

Hear hear, except for the last part.

I have worked on commercial apps where it was important to us to continually
watch:

    1. X server connection
    2. socket/tty port to other device
    3. child processes

We ended up faking it with select() and pid-specific non-blocking wait() calls.

Someday select() or its designated successor should be able to allow waiting
on an arbitrary list of inputs. Why not throw in SysV mutex objects as well.
Mapping all these sorts of things into the filesystem makes it natural for
select() or something like it to "just work".

Todd Whitesel
toddpw @ best.com