Re: [Nbd] [PATCH] define error values as part of the protocol

[Paolo Bonzini <pbonzini@...696...>]

On 14/05/2015 12:25, Wouter Verhelst wrote:
> Also, we should indeed stick to errno numbers for backwards
> compatibility, but there's no reason why we wouldn't be able to create a
> separate set of numbers (with a high bit set, e.g.) for errors that
> can't be properly expressed with errno numbers, and I'm not sure if
> mapping ENOMEM in this manner is a good idea.

Right.  But ENOMEM technically could have happened before.

> As to whether ENOMEM should be a fatal message in the protocol or not?
> Not sure.

I don't think so.  Let the client worry about it.  They can always
decide to disconnect if they get ENOMEM, or they can get into a recovery
mode with some kind of exponential backoff, or...

And of course the server can always exit(1) if malloc returns NULL.

Sticking policy into the protocol sounds like a road to people thinking
they must be an exception and not following the documentation.

> Thoughts?
> 
>> - EDQUOT is not part of the universal set of errors; it can be changed
>>   to ENOSPC on the wire format.
>>
>> - EFBIG is part of the universal set of errors, but it is also changed
>>   to ENOSPC because it is pretty similar to ENOSPC or EDQUOT.
> 
> Yeah, that makes sense.

Good, that was the part that I was worried about. :)

Paolo