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

[David Walter]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

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

Right, Wolfgang  mentioned that, and I  had  a brief  irc conversation
with Nick.

>> 2. write is disabled, i.e. return EOPNOTSUPP.
> More appropriate would be EROFS

Okay. Thanks.

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

If this is to  maintain compatibility  with Posix/UNIX, shouldn't  the
mount command manage the  insertion of records?  If  that is  the case
the rest of my issues disappear as well.

So anyway,  my rationale was to separate   the interface io interface.
Thinking that by  creating a single interface  to update  the table is
cleaner. If not, oh well, I just learned  somethings I didn't know how
to do before.

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

Well in truth the first pass did this, I can  comment out one line and
make trivfs_support_write true, and have write support back, That is:

     echo /dev/hd0s1 / ext2 rw 0 0 > /var/run/mtab

     cat /var/run/mtab
     /dev/hd0s1 / ext2 rw 0 0

     df ... 

and so on.

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

This sounds like what I meant by notification.


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

Who controls when this is done? 

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

The same way that you suggested above.


> 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

That's all   fine it does  give an   extension to support   user space
mounted filesystems.

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

Does it  not even know  the inode that  it is on?  If  it did can't it
walk up the dir tree.

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


Meaning, I suppose that there is no need  to extend the interface?  In
that case wouldn't it make sense to have mount do this.

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

I don't see why  not?  Or rather, it  seems like the reverse  would be
preferable. To make the exceptional case  be a --no-mtab option to the
translator to   not include it, then when   testing or working without
permissions  to update the system mtab,  the person  can choose not to
include  it for testing.   Then   mounts of system are   automatically
registered, whether mount is used with user mounts from /etc/fstab.

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

Don't these  permissions match the decisions of  mount and the records
of fstab? Should mount control the insertions?

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

Okay, seems like I'm playing 20 questions with  this one.  If df looks
in  /var/run/mtab is  that where  it  goes on a GNU  system  or  is df
broken?  :)

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

I  don't  understand,  why   use  a close  hook,    why  not use   the
trivfs_S_io_write?   Wait  a minute?  Here do   you mean that when the
translator calls   it's close hook it   removes it's entry?   But that
contradicts the  design that you  suggested where the  mtab translator
monitors the control port of the filesystems it has registered?  I must be 
misunderstanding something :-(  

-- 
Hurd References:
http://www.gnu.org/software/hurd/
http://www.freesoftware.fsf.org/thug/gnumach_hardware.html
http://ftp.walfield.org/pub/people/neal/papers/hurd-installation-guide/english/hurd-install-guide.html
http://www.vmlinux.org/twiki/bin/view/Hurd/WebHome