On 05/17/2016 09:58 AM, Richard W.M. Jones wrote: > On Tue, May 17, 2016 at 09:52:30AM -0600, Eric Blake wrote: >> so it might be nicer to >> make a change to the protocol document that instead permits current >> nbdkit behavior and puts the burden on clients to interoperate when >> NBD_OPT_LIST is not supported. > > The purpose of nbdkit is to be a server for qemu, to be a replacement > for qemu-nbd in cases where proprietary code cannot be combined with > qemu for copyright/licensing/legal reasons. So we aim to make sure we > can interoperate with qemu. No need to change any standards for > nbdkit! Clarifying standards documents is OK though. I also noticed that nbdkit forcefully rejects a client that sends more than 32 NBD_OPT_ commands, even though this is perfectly valid behavior on the part of the client. Maybe the protocol should document a (higher) limit on minimum number of options a client can expect to be serviced before the server dropping the connection because the client is wasting the server's time. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature