Re: [Qemu-devel] [PATCHv2] Strawman proposal for NBD structured replies

[Wouter Verhelst]

Morning,

On Wed, Mar 30, 2016 at 07:59:15AM +0100, Alex Bligh wrote:
> On 30 Mar 2016, at 00:17, Eric Blake <address@hidden> wrote:
> >> 
> >> -The server replies with:
> >> +Replies take one of two forms. They may either be structured replies,
> > 
> > Hmm, you put your strawman directly in the 'transmission phase' section,
> > while mine is deferred to the 'Experimental Extensions' section, at
> > least until we have a reference client and server implementation.
> 
> Yeah, my wording was straw man but I think it should go into the main
> body of the work. Obviously in that case it wouldn't be *merged* until
> we had a working implementation.
> 
> The SELECT stuff is a bit different as I am not sure it was intended
> to be standardized short term (i.e. it was a longer term experiment
> IIRC).

Actually, I plan to implement that when I get around to doing STARTTLS
(which I've started work on, but is far from ready).

> I guess Wouter should be the arbiter of whether he'd prefer to merge
> it only when we have an implementation. My concern is that it may
> hang around in 'experimental', when it needs properly merging, which
> will require re-wordsmithing.

I'll merge whatever the outcome of this discussion is in the
experimental section; that way, it won't get lost. I can reformulate
your text to fit there myself if needs be, although obviously having
something that doesn't require such work is preferable. However, I'm
leaning more towards Eric's proposal at this time, because it feels more
mature.

[...]
> >> +Each chunk consists of the following:
> >> +
> >> +S: 32 bits, 0x668e33ef, magic (`NBD_STRUCTURED_REPLY_MAGIC`)
> > 
> > I see you cribbed the number in my original proposal; I got my number
> > from bash's $RANDOM; I don't know if you have any underlying scheme for
> > other magic numbers in use (such as consecutive HEX digits from pi, or
> > something with ASCII meaning, or something in l33t-speak), so I'm fine
> > if anyone has rationale for why a better magic number would be desirable.
> 
> Yes I did, and no idea!

The oldstyle magic ('cliserv_magic') and the request/reply magic numbers
were made by Pavel, who invented NBD. I have no idea how he chose his
numbers, either.

The newstyle magic ('opts_magic') is ASCII for IHAVEOPT. It is used as
the magic number for option haggling, too.

There are no further magic numbers in the NBD protocol.

[...]
> >> +
> >> +Possible values of `NBD_CHUNKTYPE` are as follows:
> >> +
> >> +* 0 = `NBD_CHUNKTYPE_END`: the final chunk
> >> +* 1 = `NBD_CHUNKTYPE_DATA`: data that has been read
> >> +* 2 = `NBD_CHUNKTYPE_ZERO`: data that should be considered zero
> >> +
> >> +The format of the payload data for each chunk type is as follows:
> >> +
> >> +##### `NBD_CHUNKTYPE_END`
> >> +
> >> +S: 32 bits, error code or zero for success
> >> +S: 64 bits, offset of error (if any)
> >> +
> >> +##### `NBD_CHUNKTYPE_DATA`
> >> +
> >> +S: 64 bits, offset of data
> >> +S: (*length-8* bytes of data as read)
> >> +
> >> +##### `NBD_CHUNKTYPE_ZERO`
> >> +
> >> +S: 64 bits, offset of data
> >> +S: 32 bits, number of zeroes to which this corresponds
> > 
> > Structure wise, our reply types look similar, even though the naming is
> > different.  I also had two more types (no data, used for success, and a
> > distinct error without offset type, rather than special-casing -1 as
> > indeterminate offset).
> 
> Yours is better.

I now realize, after having slept over it, that you guys probably meant
for an error-with-offset to only mark bytes that were part of *that*
particular reply chunk to be marked as faulty, which makes more sense
than "the whole request range from that point on", as I was interpreting
it...

[...]

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12