On 4 Apr 2016, at 22:25, Eric Blake <eblake@...696...> wrote: > On 04/04/2016 03:07 PM, Alex Bligh wrote: >> >> On 4 Apr 2016, at 21:26, Eric Blake <eblake@...696...> wrote: >> >>> Huh? The current proposal _requires_ these to be separate queries. You >>> cannot query dirtiness at the same time as allocation, because the value >>> of NBD_CMD_FLAG_DIRTY is distinct between the two queries. >> >> OK, so you can ask for either (1) or (2), but not both. I see. I misread >> that. I still think Denis's idea of selecting a bitmap to query works better. > > I'm still not sure I follow what you are proposing in 'selecting a > bitmap', at least not without also needing to expand the protocol to > allow for a structured command that has more than a fixed-length message > size (currently all commands except NBD_CMD_WRITE) or a self-described > size (NBD_CMD_WRITE). Whether it's an integer, or a UTF-8 string or whatever, we'd need a way to expand the command structure. An easy way to do that would be a command flag 'NBD_CMD_FLAG_EXTENDED_COMMAND' which means the command was immediately followed by 0000 32-bit: command extra-length 0004 variable length data > Would this bitmap id be specified as an integer > (32 bits?) as an arbitrary UTF-8 string? or as something else? Or a 128 bit unique identifier (i.e. a packed UUID) to identify a bitmap. That would obviate the need for a registry of such things. That or the UTF-8 string > And > since we _already_ documented that querying dirty information requires > out-of-band coordination, why can't the out-of-band communication convey > the bitmap selection, so that the NBD command then just reads the dirty > status of the already-selected bitmap? I suppose I was trying to make a single 'read bitmap' command, that read an arbitrary bitmap. We then define one 'well known' bitmap as 'allocation'. You can have your qemu bitmap(s) to do whatever you want. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail