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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
