[Top][All Lists]

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

Re: Unionmount: proxying the control port

From: Sergiu Ivanov
Subject: Re: Unionmount: proxying the control port
Date: Mon, 10 Aug 2009 16:40:04 +0300
User-agent: Mutt/1.5.18 (2008-05-17)


On Fri, Aug 07, 2009 at 11:00:03PM +0200, address@hidden wrote:
> On Mon, Aug 03, 2009 at 08:59:15PM +0300, Sergiu Ivanov wrote:
> > On Sat, Jul 18, 2009 at 07:21:59AM +0200, address@hidden
> > wrote:
> > If so, unionmount could be used with a bootstrap filesystem in the
> > case of LiveCDs, for instance.
> Exactly.

Hm, then it probably makes sense to look at implementing the bootstrap
fsys_* RPCs in the future.  IIRC, LiveCDs are big requestors of
unioning functionality, so being able to work in this context would be
a nice feature.
> > > > * 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.
> I must admit that I don't remember what the problem was there...

The problem is as follows.  Usually, when you want to overload the
default implementation of a stub (like netfs_S_file_set_translator),
you just redefine this function in your code (which I successfully did
for netfs_S_file_set_translator in nsmux, IIRC).  However, when I try
to do the same with netfs_S_fsys_* RPCs, my new functions are not
called, so I fail to do the simple overloading.

There probably is a way around this problem, but I think I will
address this later, when I will have accomplished the time-critical
objectives of the project.


reply via email to

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