Re: Linux style /proc filesystem translator

[Jon Arney]

Marcus,

Thanks for all your feedback.  I've responded to most of the points
below.

> 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.

Actually, I didn't even know it existed.  If you point me at the source,
I'll look at it and see if it's useful to me.

> 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.

What you say is probably correct, however, inadequate models are often
still useful :)  I am not suggesting that Hurd utilities stop using
'libps' in favor of parsing data from /proc.  Clearly, this is not an
appropriate approach for the Hurd.

> 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.

Yes, I realize that /proc under Linux is a hack and has a reason for
existing.  Its evolution made sense to the architecture (even if the
design was ad-hoc).

After writing it, I also realize that the data obtained through /proc
comes from a multitude of sources under the Hurd because of the
division of responsibilities in the system.

> 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.

My reasons for doing it were to a) learn the Hurd architecture, get
warmed up for a more "substantive" project. and b) to get a little
"feeling of home" as you put it.

When I tell Linux users about the Hurd, the first question out of their
mouths is 'what does /proc' look like.  They rarely listen to
the full architectural schpiel and sort-of tune out.  Part of the
"value"
in supporting some of the "legacy" applications and interfaces is in
winning over more users which will ultimately (in my opinion) lead to
greater interest in developing on and for the Hurd, shaking out bugs,
etc.

> 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.

I agree with this point and as I was hacking, it occured to me that some
of the Hurd translators should/could provide more information about what
they're doing.  For instance, I could imagine that /hurd/pfinet could
support a filesystem-like structure showing routing information and
statistics.  I didn't think, however, that it would be appropriate to
just dive into one of those things until I understood what I was doing
well enough to avoid screwing up anything.

On this same point, I would also like to make sure that the core
translators don't grow without bound.  That is, I can envision the
use of these translators in embedded systems in which the presence
of a filesystem interface in /hurd/pfinet would just add "bloat"
to a system which might never use it.  If one wants to put more
filesystem-like interfaces on some of these translators, it might
be a good idea to make sure they can be easily compiled out.

> 
> > 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]

Another good idea.  Forgive my simple-minded-ness, but a simple
approach to the problem might be for filesystems to voluntarily
register themselves by simply writing to /etc/mtab as a real
file.  Is this a job that really needs a translator to do?
Writing an RPC to a translator is similar to simply opening /etc/mtab
(except of course, for the root which might require special
consideration).

Thanks for all the feedback!

-- 
------------------------------------------------------------------------
Jonathan S. Arney
Software Engineer
jarney1@cox.net
------------------------------------------------------------------------