Ronald Khoo writes:
> [ saw this in port-i386 where it's definitely in the wrong place.
>   we don't have a tech-religion list though :-/  ... ]
> 
> > The problem is simple: you can't read /proc from your kernel core
> > dump!
> 
> 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.

When the implementation is complete, please let me know. :-/

> It goes a bit deeper than that.  Yes, there's the hack value of
> "proving" that the 4.4BSD filesystem code "could do it" but I
> certainly do remember at least jsp being very taken with the
> Plan 9 extension of the unix "all the world's a file" abstraction
> principle to its logical limit, which is what provided the motivation
> for the hack value in the first place.

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.

> Certainly the idea that /bin/ps should just be an awk script is
> something that should be attractive to any minimalist, but the
> point that makes it a religion is that it just moves the work
> elsewhere.

As I said, though, what makes it *more* than religious is that it
hurts coredump debugging a lot. I am far from certain that you could
actually implement the "userland procfs" idea that you mention.


Perry