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