Re: Linux style /proc filesystem translator

[Marcus Brinkmann]

On Thu, Mar 21, 2002 at 09:25:19AM -0700, Jon Arney wrote:
> I've been busy the last week or so putting together a first pass at
> a Linux style /proc filesystem translator. 

Do you know about Neal Walfields procfs which he wrote a couple years
ago?  He says it is broken but it might be worth looking into for you.

> was to start with a Linux-2.4 style /proc filesystem and then move
> on to bigger and better by supporting a 'native' Hurd mode /proc
> filesystem which models the Hurd's behavior better rather than
> just emulating a Linux style /proc.  i.e. rather
> than /proc/<pid>/* we might have /proc/tasks/<pid>/<thread>/*
> and /proc/tasks/<pid>/<children>/* and other cool stuff.  

It is not really clear to me that any procfs would model the Hurd
adequatly.  In fact, the Hurd already has its own models, like the
individual translator settings.  Or, for processes, we have libps, which
is a library and is much better than parsing a filesystem.

Note that there is a hard reason for Linux to use a procfs.  First, they
don't have any really good interface to communicate with the system,
whereas the Hurd has not only the whole filesystem but also the remote
procedure call interfaces to communicate with they system interface.
Second, it is easier for them to lump everything together into a single
directory hierarchy, because procfs is just a hack, and no design
concept of the system.  In the Hurd, the individual system components
provide their own interfaces at their location, and a lot of the
flexibility of the Hurd stems from the fact that their is _no_
monolithic block that keeps control or has the information.

This basically means that something like a procfs can never be an
integral part of the system, because it doesn't fit in conceptually.
however, it might be useful anyway, be it to learn about translators, to
give Linux users a touch of "feeling at home" or even for compatibility.
But if you ask about the Hurd way of doing things, procfs doesn't really
come into the answer at all.  For the Hurd, procfs is, conceptionally,
already everywhere you look.

That is not to say that there shouldn't be a filesystem view at the
process table.  Maybe it can even be provided by the proc server itself,
making it a filesystem (but maybe better not for robustness).
A more appropriate place if you only talk about processes would then be
/servers/proc.  If you talk about partitons of hd0, /dev/hd0/ (as a
directory rather than a file, which it also would be) might be an idea.

> The beauty (and danter) of the Hurd is that it's an entirely
> independent package and doesn't need to be compiled into the
> /hurd tree. 

Yep, that was one of the design goals in the first place.  The above is
not really to discourage you from the hacking, but maybe it kicks off
some ideas (sticking to Linux style fs makes sense if you want to
provide Linux binary compatiblity, which is one of the long term goals,
otherwise, feel free to be much more creative ;).

(The following should be one or two paragraphs up, as an example for a
non-hurdish but still useful translator, but I don't know how to copy
and paste in vi).
For example, I also think we should have an mtab translator that
filesystems can register themselve voluntarily (for example when you
specify the commandline option --mtab /path), for compatiblility with
Unix (so that df is a little more helpful).  (nickr is working on that).
And this, although associating a filesystem with a path name is utterly
broken conceptionally :) [note: the opposite, associating a path name
with a filesytem makes perfectly sense]

Thanks,
Marcus