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

[Marcus Brinkmann]

On Mon, Jul 22, 2002 at 03:04:58PM -0400, David Walter,,, wrote:
> Hi.  Is there a way to return the path name from a port?

Not really.  The official answer is no, as a port doesn't need to be linked
into the filesystem under any filename.  For some directories, there is
_hurd_canonicalize_directory_name_internal, which of course should not be
used.

> I'm trying to implement an mtab translator.

Nick is also working on it, following a design we discussed some time ago.
In the design I came up with, there was no need to get the path from a port.
 
> 2. write is disabled, i.e. return EOPNOTSUPP.

More appropriate would be EROFS
 
> 3.  insertion of a new entry  by using a  utility program mtab_client.
> currently  uses getline to  read in a  mount record.  A mig definition
> file has been generated to create an insert of a record, the arguments
> are a  string and the  strings length. The record  is  parsed from the
> string using sscanf.

It's better to not add a new interface if it is not needed.

In case you only need to transfer strings, why not make it part of the write
support?  If a file is opened, the caller can write the string to it.

> I am  thinking that a natural  way to handle  the call to insert a new
> file system would  be for  the translator  /hurd/{*fs} to  make a call
> with just  their mount  point. mtab  could then find  all  information
> about that filesystem by asking the translator.

Indeed.


My plan was like this:

The translators get a new option, --mtab FILE, which specifies a pathname
that should be written to /etc/mtab.  /etc/mtab has the mtab translator on
it.  For each open that includes the writable bit, it accepts one line
written with a pathname.  As long as the port is kept open, it will include
this pathname in its output.  When the port is deallocated, the entry is
removed from the output.  The filesystem will keep the file open as long as
they live (this way, we will get notified when the filesystem dies).

The translator can write another line to the file, and then it will replace
the older one in the output.

> This seems like it would  have two benefits,  by installing a hook for
> watching  the translator, (1)if/when it  dies the entry can be removed
> from mtab, (2) end  users don't have to  know about additional options
> to filesystem translators which cause updates to mtab.

I don't really see how in your scheme the mtab translator gets notified of
filesystem death.  The problem of determining the pathname is the same in
your and my model.  I solved it by adding an option, because I think this is
the price you have to pay for Unix compatibility in this issue.


More ideas:

* The filesystem can register itself with /etc/mtab, or with other mtab
  translators, honoring the MTABSERVER environment variable.

* df is extended to read from /etc/mtab and ~/.mtabrc

> Problem:
> 
> I can't   find  a way to  determine   the mount  point  reliably in  a
> translator, as  it's cwd isn't necessarily  the same at startup as the
> node for which it translates.

It's cwd is completely unusable, esp for passive translators.

You are hitting a limit in Unix/POSIX design here.  mtab actually reflects a
very simplistic ideal of how filesystems are handled in Unix.   The basic
assumptions behind it, that all filesystems have on mount point that is
controlled by the kernel, is justn ot true in the Hurd.  So, we have to find
a compromise that gives the us the basic functionality people expect from
df.

Having an option --mtab has the advantage that you only see filesystems that
are configured to be included in the output.  You don't want all filesystems
to register themself.

Also, you should make write permission on the node restrictive, because only
system filesystems should be in /etc/mtab.  User filesystems can be in
~/.mtabrc or sim.
 
> As a  temporary kludge I have added  a settrans call in /libexec/rc. I
> notice that this deletes all files in  /var/run on startup.  Thus this
> translator doesn't exist across reboots.  Will a production GNU system
> run
>         settrans -cap /var/run/mtab /hurd/mtab 
> 
> at each system startup?

Only if /var/run is the place to put it into, and we remove all files in
there. ;)
 
> I haven't figured out notification  yet, if anyone has tips, pointers,
> example code I will be happy to have them.

If you use write support, the normal close hook is the way to go.
 
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/