On Fri, Mar 03, 2023 at 04:40:38PM -0600, Eric Blake wrote: > On Wed, Feb 22, 2023 at 12:05:44PM +0200, Wouter Verhelst wrote: > > On Mon, Nov 14, 2022 at 04:46:54PM -0600, Eric Blake wrote: > > > #### Simple reply message > > > > > > @@ -1232,6 +1235,19 @@ The field has the following format: > > > will be faster than a regular write). Clients MUST NOT set the > > > `NBD_CMD_FLAG_FAST_ZERO` request flag unless this transmission flag > > > is set. > > > +- bit 12, `NBD_FLAG_BLOCK_STATUS_PAYLOAD`: Indicates that the server > > > + understands the use of the `NBD_CMD_FLAG_PAYLOAD_LEN` flag to > > > + `NBD_CMD_BLOCK_STATUS` to allow the client to request that the > > > + server filters its response to a specific subset of negotiated > > > + metacontext ids passed in via a client payload, rather than the > > > + default of replying to all metacontext ids. Servers MUST NOT > > > + advertise this bit unless the client successfully negotiates > > > + extended headers via `NBD_OPT_EXTENDED_HEADERS`, and SHOULD NOT > > > + advertise this bit in response to `NBD_OPT_EXPORT_NAME` or > > > + `NBD_OPT_GO` if the client does not negotiate metacontexts with > > > + `NBD_OPT_SET_META_CONTEXT`; clients SHOULD NOT set the > > > + `NBD_CMD_FLAG_PAYLOAD_LEN` flag for `NBD_CMD_BLOCK_STATUS` unless > > > + this transmission flag is set. > > > > Given that we are introducing this at the same time as the extended > > headers (and given that we're running out of available flags in this > > 16-bit field), isn't it better to make the ability to understand > > PAYLOAD_LEN be implied by extended headers? Or is there a use case for > > implementing extended headers but not a payload length on > > CMD_BLOCK_STATUS that I'm missing? > > In my proof of implementation, this was a distinct feature addition on > top of 64-bit headers. > > It is easy to write a server that does not want to deal with a client > payload on a block status request (for example, a server that only > knows about one metacontext, and therefore never needs to deal with a > client wanting a subset of negotiated metacontexts). Forcing a server > to have to support a client-side filtering request on block status > commands, merely because the server now supports 64-bit lengths, > seemed like a stretch too far, which is why I decided to use a feature > bit for this one.
Okay, yes, that makes sense. Thanks. -- w@uter.{be,co.za} wouter@{grep.be,fosdem.org,debian.org} I will have a Tin-Actinium-Potassium mixture, thanks. _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs