Re: [Libguestfs] [libnbd PATCH 4/4] api: Add DF flag support for pread

On Tue, May 28, 2019 at 10:23:13AM -0500, Eric Blake wrote: > But having some sort of callback that gets invoked > on each chunk would allow the client to add in such checking; we could > even provide a utility function in the library to serve as such a > callback if our checking is sufficient for the client's purposes. > Something like: > > nbd_pread_callback(nbd, buf, count, offset, opaque, callback, flags) > > where we still read off the wire into buf (to avoid ping-ponging a read > into a temporary buf that the callback then has to memcpy() into the > real buf), but call the callback as soon as each chunk is received: > > callback(opaque, buf, count, offset, status) TBH this looks like the most simple & sensible API to me. > telling the user which subset of buf was just populated, and where > status is data, hole, or error. The signature may still need tweaking. > Or we may even want to let the user register a set of callbacks, where a > different callback is invoked for different chunk types: > > set = nbd_callback_set_create(nbd, NBD_CMD_READ, opaque, default_cb, > default_error_cb); > nbd_callback_set_add(nbd, set, NBD_REPLY_TYPE_OFFSET_DATA, opaque, cb); > nbd_callback_set_add(nbd, set, NBD_REPLY_TYPE_OFFSET_HOLE, opaque, cb); > nbd_pread_callback(nbd, buf, count, offset, set, flags); This would also work, with the caveat that the Python bindings will currently crash if you try to do this. I'm trying to fix that now.

> The idea of registering a set of callbacks to handle a particular > integer command id may work well for other extensions as well; > particularly if we encounter a case where an app wants to use libnbd for > the groundwork (setting up a tls connection handshake) but still > implement their own non-standard NBD extensions that the server will > understand (where the libnbd state machine parses the chunks off the > wire, but the client then interprets those chunks). Which means we may > also need hooks for a client to inject other NBD_OPT sequences into the > state machine beyond what we know natively. This could be interesting too. I wonder if there are really going to be such extensions? > Various ideas still floating around, it may be a while before we > actually have code to match those ideas in order to pick what works best. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html _______________________________________________ Libguestfs mailing list Libguestfs(a)redhat.com https://www.redhat.com/mailman/listinfo/libguestfs