Re: [Nbd] [PATCH v3 2/2] doc: Add details on block sizes

[Wouter Verhelst <w@...112...>]

On Thu, Apr 14, 2016 at 05:52:06PM +0100, Alex Bligh wrote:
> >> Could we not just use one of the client flags? We have 32 bits of
> >> them (as opposed to 16 server flags). It's right at the start
> >> of the negotiation, and we simply need to refer to whether
> >> NBD_FLAG_C_BLOCKSIZE is set. It can be in the top 16 bits if we
> >> don't want to use a flag which can match a server flag.
> > 
> > No: we already document "the server MUST drop the connection if the
> > client sets an unknown flag, or a flag that does not match something
> > advertised by the server."  The only way for the client to use a client
> > flag rather than an NBD_OPT_ is for the server to first burn a global
> > flag, because otherwise, a new client setting the flag but talking to an
> > older server would never get past flag negotiation and have no good
> > error message to show for it.  Whereas with NBD_OPT_, the client is at
> > least guaranteed a sane NBD_REP_ERR_UNSUP; and we have a lot more room
> > for adding new NBD_OPT_ (2^16) compared to adding new flags (2^5 global,
> > 2^6 client).
> 
> Arrggh yes. So either we burn a global flag or we use an NBD_OPT, and
> add statefulness in the receipt of NBD options (i.e. the server
> now has to remember whether it's seen this option).

global.used_option_flags |= NBD_F_BLOCKSIZE;

> Neither of these are especially pleasant. I think I'd prefer burning the flag
> :-( Wouter?

I want to keep "burning a flag" for things that break backwards
compatibility in some way, precisely because they're hard enough to
expand, and their availability is fairly limited.

Yes, it's unfortunate that the client flags and handshake flags have
different sizes, but that can't be helped now.

-- 
< 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