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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
