bug-hurd
[Top][All Lists]
Advanced

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

Re: Unionmount: proxying the control port


From: olafBuddenhagen
Subject: Re: Unionmount: proxying the control port
Date: Sat, 11 Jul 2009 02:30:30 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

Hi,

On Wed, Jul 08, 2009 at 09:39:06PM +0200, Carl Fredrik Hammar wrote:
> On Wed, Jul 08, 2009 at 03:41:51PM +0300, Sergiu Ivanov wrote:
> > On Tue, Jul 07, 2009 at 09:50:12PM +0200, Carl Fredrik Hammar wrote:
> > > On Tue, Jul 07, 2009 at 08:55:37PM +0300, Sergiu Ivanov wrote:

> > > > * fsys_set_options: This RPC should be forwarded to the mountee
> > > > completely.  unionmount does not have any command line switches
> > > > that would make much sense being altered at run-time.
> > > > 
> > > > * fsys_get_options: This RPC should be forwarded to the mountee
> > > > completely.  The reasoning is the same as for fsys_set_options.
[...]
> Perhaps I should clarify, I meant that it doesn't make sense to
> forward the RPC completely if implemented in unionfs, since unionfs
> does have run-time options that users might want to fiddle with.  That
> is, forwarding should only be done for the --mount option.

Well, we are only talking about the transparent case (--mount) here --
the unionfs translator hides itself completely in this case, and things
look just as if the mountee were sitting directly on the underlying
node. In this case, we definitely want to forward these RPCs.

For the non-transparent case (--no-mount), we do not proxy the control
port at all; the unionfs translator handles all fsys_ RPCs itself. You
are right that it *could* be useful if the --mount arguments were
forwarded to the mountee when doing fsysopts -- but this is a different
matter :-)

-antrik-




reply via email to

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