[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Walter
Subject: Re: mtab (was: Re: path+file_name from port or process info?
Date: Thu, 25 Jul 2002 15:03:40 -0400
User-agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-unknown-gnu0.2)

Marcus Brinkmann <address@hidden> 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?

> or  they run  suid/sgid,  and they   run as  root, they  should  use
> _PATH_MOUNTED if it exists.  If they run as normal user, they should
> use $HOME/.mtab (or something similar) if it exists.  They should do
> whatever is necessary to register themselves with this filesystem (I
> think writing a single line with the path is the  thing to do -- the
> rest can be derived by mtab).

I  prefer the translator   knows when  to  insert  itself idea to  the
fsysopts plan.

Let's see when should a translator insert itself into / notify mtab?
and vice versa.

1. a system file system that is auto mounted

   a) a filesystem declared in /etc/fstab

   b) a passive translator for a filesystem which is sitting on a node
   with suid,sgid set or root ownership.

   c) same as b, but started with  mount or settrans by  a user who is
   the same.

2. a file system that shouldn't be included might be:

   a) an experimental filesystem

   b)  one that is  hidden from  users  for  some reason

> df should check _PATH_MOUNTED and $HOME/.mtab (or something similar) and
> concatenate the output.

Right, this makes sense.

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

Why should the user  want to change the  path that mtab registers?  Is
this to address the mount point moved problem you noted later?

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

> Now, what about the following questions:
> * Can a translator determine the path to be registered with mtab
>   automatically?
> * If yes, which translators should do this by default, unless --no-mtab is
>   given.
> I think the _hurd_canonicalize_dirname_internal function is worth trying
> out.  It might just be what we want in the normal case, which will certainly
> be 99% of the cases.  The rest can use --mtab explicitely.  Also, if you
> move the filesystem, you need to kick off a change to mtab manually[2].

Hmm. I have tried this.  In the simple case of 
     file_t f;

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)

None of these seems to be correct.

Then I tried the following:

error_t (*trivfs_protid_create_hook) (struct trivfs_protid *) = 

where the following looked promising.

   realnode = protid->realnode;

This fails to be the correct item also, apparently.

So I began to track backward in the process.

It looks   like  settrans   sets  the active    translator  using  the
fshelp_start_translator function.

this uses a callback defined in  settrans (this is for my information,
you are probably more familiar with this process, sorry for the boring
details) open_node.

open_node sets     the   node  variable    (file_t  node)    based  on
file_name_lookup, which is then passed to file_set_translator.

>From   here  I  get  lost  as  the  following  look  like the function
file_set_translator   but don't seem   to match in behaviour.  Perhaps
I've got mismatched headers or something, but a grep-find of libc hurd
and gnumach sources yields several file_set_translators.

Unfortunately  for me I can't  find  where the  implementation of  one
matches, the mig definitions or fs.h.

>From fs.h

        file_t file,
        int passive_flags,
        int active_flags,
        int oldtrans_flags,
        data_t passive,
        mach_msg_type_number_t passiveCnt,
        mach_port_t active,
        mach_msg_type_name_t activePoly

>From libdiskfs:

/* Implement file_set_translator as described in <hurd/fs.defs>. */
diskfs_S_file_set_translator (
               struct protid *cred,
                              int passive_flags,
                              int active_flags,
                              int killtrans_flags,
                              char *passive,
                              size_t passivelen,
                              fsys_t active)

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

I was hoping  that I could find some  underlying call that carried the
file_t that  the mtab translator can copy  from, but I must be missing
the mark on that.

> [2] Unless you go for a very complicated and somewhat expensive solution and
> request dir notification messages on all dir nodes that are in your path, and
> then act on rename operations properly.  Which is, again, not guaranteed to
> work, but would be the honest attempt approach at doing the right thing.
> However, I think this is overkill, for the following reason:  The
> things you want in mtab are the permanent filesystems like /, /mnt, /cdrom,
> etc, which usually are not moving around a lot.  The more dynamic filesystems
> should not be registered with mtab anyway.

Right, this  is  a potential  problem  but the ramifications  of  this
aren't clear until I can see that the trivfs_* translator actually has
access to the underlying node in some way?

Hurd References:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]