Re: mtab (was: Re: path+file_name from port or process info?

[Marcus Brinkmann]

On Thu, Jul 25, 2002 at 03:03:40PM -0400, David Walter wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > Translators should check   if they run  suid  or sgid, if not,  they
> > should check if $MTABSERVERS is set and use that.  If it is not set,
> 
> Did you mean   for this to be  plural?  If so how would  an translator
> decide which of any $MTABSERVERS to insert into? Or would you have the
> translator insert into _all_ of them?

No, sorry, just a single path in $MTABSERVER.
 
> I  prefer the translator   knows when  to  insert  itself idea to  the
> fsysopts plan.

The problem is that with all the funny translators we have, there will never
be a hard rule for when a translator is "interesting" enough to be in mtab
and when not.

How does df avoid listing /proc?

> > The user should be able to override (and change at runtime) the path that
> > the translator registers with mtab by setting --mtab PATH.  It should be
> > able to suppress registration (unregister at runtime) with --no-mtab.
> 
> You've lost me on part a of this. 

This applies if you can not (or don't want to) find out the path name of the
translator.  In this case, the user must pass it on the command line so the
translator knows under which path it can be found.
 
> Why should the user  want to change the  path that mtab registers?  Is
> this to address the mount point moved problem you noted later?

If the mtab server has to use a weird filename to find the translator, not
the one the translator thinks it is attached to, you have to set it
manually, with your local configuration in mind.

You still seem to think in terms of traditional Unix filesystems.  Forget
all this, nothing is true in the Hurd anymore.  Throw all assumptions over
board.  How a process perceives the filesystem hierarchy is completely and
entirely virtual, and can differ from process to process.  Although the
filesystem itself might think it is attached to /mnt (following
_hurd_canonicalize_filename_directory_internal), the mtab server might have
to use a different path, let's say /otherfs/mnt, and the df program might
have an even different view on the filesystems (itm ight not be able to find
/mnt at all).  Of course, this requires some special setup, it's not the
default.  But if you divert from the default, which can be a very useful
thing to do, you might need the added flexibility of changing the filename.

This is why I hesitate about _hurd_canonicalize_filename_directory_internal,
it gives you the information based on what the translator sees, while you
really want the information based on what the mtab server (really even: what
the df program) sees.

OTOH, we already have a weirdness in that the translator will look up
_PATH_MOUNTED in _its_ namespace to register itself, while you would want it
to be the one in the user's namespace.  So we are already making a good deal
of assumptions in how the system is set up.  This tells us two things,
probably:  That we can rely on some basic sane assumptions for the whole
matter, and that we can not ever get an ideal solution, it's just a
compromise for a feature which will never fly in the Hurd world.

In other words, don't try to make it perfect.  It's not worth the effort,
because for fundamental reasons it can not be perfect.
 
> > I think so far we agree (as soon as you forget about the mount thing :)
> 
> Done(forgotten). I only mentioned that as it  seemed where we are left
> if we depend on the user to _do the right thing_ (tm).

The user can use the --mtab option to the translator :)

> I get the right thing to happen.  But where  is the node(port) for the
> underlying filesystem?
> 
> the current  iteration of  the mtab translator  is using  trivfs and I
> have so far (unsuccessfully) tried the following:
> 
>      attempt using the following from trivfs_peropen_create_hook()
>              open_hook (struct trivfs_peropen *peropen)
>              peropen->cntl->{file_id,filesys_id,underlying}.
                                                  ^^^^^^^^^^

that's the one.  From pfinet/main.c, for example:

  err = trivfs_startup (bootstrap, 0,
                        trivfs_cntl_portclasses[0], pfinet_bucket,
                        trivfs_protid_portclasses[0], pfinet_bucket,
                        &pfinetctl);

  if (err)
    error (1, err, "contacting parent");

  /* Initialize status from underlying node.  */
  err = io_stat (pfinetctl->underlying, &st);


> So where  I am stymied  is the use of  struct protid*cred, where I had
> expected to find a file_t file.

This is MiG auto-mutation, where a port is matched to a structure.  Just
ignore it ;)

Thanks,
Marcus
 
-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/