[Libguestfs] [PATCH 7/9] Implement filters.

[Eric Blake]

On 01/18/2018 03:15 AM, Richard W.M. Jones wrote:
> On Wed, Jan 17, 2018 at 04:31:31PM -0600, Eric Blake wrote:
>> (I'm also planning on rebasing my
>> FUA flags on top of your series, since so far it is looking pretty good).
> 
> I think after some thought I'm going to add a filter.open method which
> will include a next parameter (actually 2x next parameters, for
> next_open and nbdkit_next).
> 
> It's necessary to implement a copy-on-write layer that we can have a
> read-write filter which enables readonly on the layer below.  Thus it
> needs to call the layer below with open (readonly=1).
> 
> For the partition filter it makes sense that during the filter open
> call we can read the partition table from the lower layer, ie.
> issuing pread call(s) to the plugin.  Any other way to do this is very
> clunky.
> 
> However there are risks here.  In particular when we currently are in
> the .open call we haven't fully brought up the connection.  We haven't
> even done the option negotiation, but the plugin will be expected to
> handle pread() and other calls.  I need to examine the code properly
> to see if this matters.

I think we're okay there, as long as we follow my earlier life-cycle
comment: we must open things bottom-up (complete the plugin's open()
before calling the filter's open()), then process all other messages
top-down (filter gets first shot; for things like config and pread, the
filter chooses whether to call the plugin; for others like close, we
guarantee that the filter is closed first, then the plugin is closed,
without relying on the filter to forward things).

> 
> Also filter.close could be extended in the same way since closing a
> filter might involve finalizing data in some way.
> 
> Also this means we do need to define the order in which open and close
> calls are done across filters & plugins.

Yep, that means we're in agreement on layering order guarantees.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180118/97d7d512/attachment.sig>