Re: [Nbd] Processing client's option list
- To: Wouter Verhelst <w@...112...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] Processing client's option list
- From: Goswin von Brederlow <goswin-v-b@...186...>
- Date: Sun, 29 May 2011 17:18:45 +0200
- Message-id: <87lixpwn56.fsf@...860...>
- In-reply-to: <20110529133846.GA4433@...510...> (Wouter Verhelst's message of "Sun, 29 May 2011 15:38:46 +0200")
- References: <8BCC20F6E60432780CDEB0A8@...874...> <20110529092914.GC23363@...510...> <877h99bv24.fsf@...860...> <23B2AC39B03D93CD1132601E@...873...> <20110529133846.GA4433@...510...>
Wouter Verhelst <w@...112...> writes:
> On Sun, May 29, 2011 at 12:48:12PM +0100, Alex Bligh wrote:
>> --On 29 May 2011 13:33:23 +0200 Goswin von Brederlow
>> <goswin-v-b@...186...> wrote:
>> >Currently NBD_OPT_EXPORT_NAME is the only possible option and it is also
>> >required. How about declaring that NBD_OPT_EXPORT_NAME must be the last
>> >option being send and ends the negotiation?
>>
>> With the current negotiation where all the client's options are sent at
>> once, it would be fine. We could even use the current number for
>> NBD_OPT_EXPORT_NAME for NBD_END_OPTIONS (or similar) and say that
>> optionally it can take an export name for legacy compatibility.
>>
>> We could then define NBD_OPT_EXPORT_NAME as some other value.
>
> I don't really like that. It muddles which is which, and could cause
> confusion down the line. But there's not really a problem with stating
> that NBD_OPT_EXPORT_NAME has to be the last option for now, and we can
> deal with it if and when that ever needs to change.
Is the new protocol in use anywhere relevant? How long has it been out
there in the wild? Maybe this could just be fixed without backward
compatibility.
MfG
Goswin
Reply to: