On 01/14/2018 06:11 AM, Richard W.M. Jones wrote:
This patch isn't complete (patch 6/6 isn't finished) so
it's just for
discussion, although it does compile and run.
This introduces to nbdkit a concept of "filters" which can be placed
in front of plugins to modify their behaviour. Some examples where
you might use filters:
* Serve a subset of the data, such as (offset, range) or a
single partition from a disk image.
* Inject delays or errors for testing clients.
* Implement "copy-on-write" (a feature found in other NBD servers).
How hard would it be to allow filters to control what features are
advertised? For example, we've already proven that it is easy to expose
features to the end client that are not present in the plugin (we
advertise FUA support to end clients, because we can emulate it by
calling the plugin's .flush at the right places; we also advertise write
zero support because we can call the plugin's .pwrite as a fallback).
But for testing purposes, it might be nice to permit the reverse:
intentionally filter out a feature that the plugin supports, but which
we do not want to advertise to the end client, for the purposes of
testing the client's ability to fall back to other means in the absence
of that feature.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org