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: Sergiu Ivanov
Subject: Re: Unionmount: proxying the control port
Date: Fri, 14 Aug 2009 16:59:34 +0300
User-agent: Mutt/1.5.16 (2007-06-09)

Hello,

On Wed, Aug 12, 2009 at 02:42:29PM +0200, address@hidden wrote:
> Hi,
> 
> 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 :-)

OK :-)
 
> 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 :-)

Aha, I see your point :-)
 
> > 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...

I'll look into this problem as soon as I have time for it.

Regards,
scolobb




reply via email to

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