[Top][All Lists]

[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: Wed, 12 Aug 2009 14:42:29 +0200
User-agent: Mutt/1.5.19 (2009-01-05)


On Mon, Aug 10, 2009 at 04:40:04PM +0300, Sergiu Ivanov wrote:
> 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:

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

Well, as I said, I'm not sure it's even possible to use it like that...
And I don't want to think about it right now :-)

Not saying we need to implement them any time soon. My point was only
that these RPCs *might* make sense for unionmount after all -- you were
a bit too quick with discarding this possibility :-)

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

That's strange indeed...


reply via email to

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