Re: Linux style /proc filesystem translator

[Marcus Brinkmann]

On Thu, Mar 21, 2002 at 07:39:19PM -0700, Jon Arney wrote:
> 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.

Might be at Neal's web site (ftp.walfield.org), or just try google.
James has a collection on his site, I read here ;)

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

That's one of the problems.  The complementary problem is that it can't
even gather the data from all relevant sources, because there is no
repository that tells it where those sources are (eg there could be more
than one proc server).  Not that we would want it to gather the data
from all sources, this would break the encapsulation (you use a second
proc server exactly to hide your processes from the main system ;)

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

Wonderful reasons to do it, as I said.  No question about that.
I just hope that other people choose different traslators, so that
we don't end up with 20 procfs implementations over the years ;-)
OTOH, we have 40 editors and 30 window managers, so why not likewise for
/proc...

> When I tell Linux users about the Hurd, the first question out of their
> mouths is 'what does /proc' look like.

That is usually a wonderful time to explain to them why /proc doesn't
cut it on the Hurd ;)  Mmmh. Do you think the curiosity for bogo mips
/proc/cpuinfo might be a substitute for lack of other interesting
concepts in Linux... probably not...

<evil plan>
We should write up some funny /proc/cpuinfo et all and include them as
ascii files in the distribution.
</>

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

I was writing my mail without need, your thoughts already wander all in
the right directions.  Just keep going!  (Although I don't think we have
all made our mind up how to do complex configuration and reporting in
the individual cases.  A filesystem is always tempting, sometimes extra
RPCs might be better, don't rule them out when pondering it).

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

Ok, I will tell you my idea.  What you said would work, except that it
wouldn't ensure that filesystems are removed when they die.  So the mtab
server has to keep track of the server life span.  This is done with
death notification messages on mach ports.  To make the implementation
easy, I recommended toNick to just let the server open the /etc/mtab
"file" active translator) with O_WRONLY, which means that the file gets
special semantics: The server will write one line into it, which is the
path name it claims it is attached to.  The mtab server will use the
path, and lookup the port.  It will expect a translator there, and set
it the fsys_get_options rpc to retrieve the argument line.  This
includes information about the filesystem type (strip leading /hurd/ and
trailing "fs") and the file system options.  From this information, it
constructs the mtab entry (whic is of course returned as a list if you
open with O_RDONLY).  Now the trick is that the server will keep the
file handle (port to mtab) open, it does not close it.  If it wants to
update the info (mv /local/mnt /mnt; fsysopts /mnt --mtab /mnt), it just
writes another line.  The mtab server will then update the info (only
the last line written counts).  When the file handle is closed, the mtab
sevrer will remove the entry.  This can be because the user requested
that the filesystem does not register itself (fsysopts /mnt --no-mtab),
or because the server died.

The alternative to this is to have some real RPCs for this (exchanging
ports etc).  But I think this is unnecessary, as the above scheme fits
the expectations quite nicely.

Thanks
Marcus