Re: Unionmount: proxying the control port

[Sergiu Ivanov]

Hello,

On Sat, Jul 18, 2009 at 07:21:59AM +0200, olafBuddenhagen@gmx.net wrote:
> (Most of this is only for the record, as we already discussed it on
> IRC.)

I will only give some short comments to those points about which I
have to say something.
 
> On Fri, Jul 10, 2009 at 08:52:44PM +0300, Sergiu Ivanov wrote:
> > * fsys_set_options: in transparent mode this RPC should be completely
> > forwarded to the mountee; in non-transparent mode this RPC should be
> > handled in unionfs first and the (possibly) new value for the
> > ``--mount'' option should be delegated to the mountee;
> 
> I'm not actually sure whether it's useful to handle it like that in the
> non-transparent case...
> 
> And I would consider it an additional feature anyways, not really
> crucial.

I didn't implement this feature.  Since such functionality should be
an additional feature, I could try to implement it later, because it
really isn't crucial to the union mount functionality.
 
> > * fsys_getpriv: * fsys_init: fsys.defs says that these RPCs should
> > only be implemented by bootstrap filesystems; since unionfs will
> > hardly ever be a bootstrap filesystem, these RPCs will not be
> > implemented;
> 
> I'm actually not so sure about that... It *might* be useful to
> union-mount the bootstrap filesystem -- I'm just not sure whether it's
> even possible in theory :-)

I think I must ask the question which has been around my mind for some
time: what is a ``bootstrap filesystem''?  Is it a filesystem used at
Hurd startup (like ext2fs)?  If so, unionmount could be used with a
bootstrap filesystem in the case of LiveCDs, for instance.

> > * fsys_forward: in the previous discussion there is a short
> > explanation why this RPC should be left implemented in the default
> > version (returning EOPNOTSUPP);
> 
> Well, if it can be easily forwarded, we should -- it *might* be
> useful...

Unfourtunately, as it has already been discussed on the IRC, I failed
to overload netfs_S_fsys_* stubs by simple redifinition of the
corresponding functions.  This made me stick with netfs_* stubs (not
netfs_S_*) and libnetfs does not define a netfs_* stub for
fsys_forward.  Due to this situation, forwarding fsys_forward looks
like a not-really-trivial task, so I'd rather leave it for better
times.
 
Regards,
scolobb