[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) |
Hi,
On Mon, Aug 10, 2009 at 04:40:04PM +0300, Sergiu Ivanov wrote:
> On Fri, Aug 07, 2009 at 11:00:03PM +0200, olafBuddenhagen@gmx.net
> 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...
-antrik-