Re: [Libguestfs] [PATCH nbdkit] New plugin: blkio
On Wed, Jan 04, 2023 at 06:14:35PM +0000, Richard W.M. Jones wrote:
Using libblkio (https://libblkio.gitlab.io/) this implements a
plugin
for reading and writing various disk sources mainly used in
virtualization and other high performance cases. These include: NVMe,
vhost-user, vhost-vdpa and VFIO PCI.
Note the current implementation uses the simplest libblkio API mode
(blocking) and so it is not suitable for high performance access.
---
+++ b/plugins/blkio/Makefile.am
@@ -0,0 +1,80 @@
+man_MANS = nbdkit-blkio-plugin.1
+CLEANFILES += $(man_MANS)
+
+nbdkit-blkio-plugin.1: nbdkit-blkio-plugin.pod \
+ $(top_builddir)/podwrapper.pl
+ $(PODWRAPPER) --section=1 --man $@ \
+ --html $(top_builddir)/html/$@.html \
+ $<
Indentation looks odd here. Wonder if it's copy-pasted from somewhere else with an
odd mix.
+++ b/plugins/blkio/blkio.c
@@ -0,0 +1,270 @@
+/* nbdkit
+/* libblkio could do parallel, but we would need to reimplement this
+ * plugin to use the libblkio event model.
+ */
+#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS
Fair enough for a proof of concept!
+
+struct property {
+ const char *name;
+ const char *value;
+};
+DEFINE_VECTOR_TYPE(properties, struct property)
+
+static const char *driver = NULL; /* driver name - required */
+static properties props = empty_vector; /* other command line params */
+static const_string_vector gets = empty_vector; /* get= parameters */
Is -Wshadow going to complain about a potential conflict with the
obsolete gets(3) name?
+++ b/TODO
@@ -155,6 +155,13 @@ nbdkit-cdi-plugin:
* Look at using skopeo instead of podman pull
(https://github.com/containers/skopeo)
+nbdkit-blkio-plugin:
+
+* Use event-driven mode instead of blocking mode. This involves
+ restructuring the plugin so that there is one or more background
+ threads to handle the events, and nbdkit threads issue requests to
+ these threads. (See how it is done in the VDDK plugin.)
I'm also trying to figure out if a v3 plugin protocol would make this
easier. Right now, with v2, we basically block an entire nbdkit
thread from the time we parse a request from the client until the
plugin has a result (which in turn means the result is all-or-none, so
we can't support sparse reads yet). But for v3, I'm hoping to get to
the point where we can have a a way for plugins to opt in to a 2-stage
action: we inform the plugin of a user request and give it a cookie,
then it uses a callback with that cookie when it is ready with part or
all of the response. (Plugins that are okay with simpler blocking
semantics will still work as they do in the v2 plugin protocol).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org