From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbqY6-0005ml-OL for qemu-devel@nongnu.org; Tue, 15 Sep 2015 09:45:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbqY0-0008Jc-LG for qemu-devel@nongnu.org; Tue, 15 Sep 2015 09:45:30 -0400 Date: Tue, 15 Sep 2015 15:26:29 +0200 From: Kevin Wolf Message-ID: <20150915132629.GD3986@noname.str.redhat.com> References: <1441878905-5272-1-git-send-email-wency@cn.fujitsu.com> <1441878905-5272-2-git-send-email-wency@cn.fujitsu.com> <87r3m1krdl.fsf@blackfin.pond.sub.org> <55F6EBF5.2090101@redhat.com> <55F776CC.3050601@cn.fujitsu.com> <87fv2g876a.fsf@blackfin.pond.sub.org> <55F8172B.5020209@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <55F8172B.5020209@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 1/5] support nbd driver in blockdev-add List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Alberto Garcia , qemu block , Jiang Yunhong , Dong Eddie , Markus Armbruster , qemu devel , Gonglei , Stefan Hajnoczi , Yang Hongyang , "Dr. David Alan Gilbert" , zhanghailiang --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 15.09.2015 um 15:03 hat Eric Blake geschrieben: > On 09/15/2015 01:37 AM, Markus Armbruster wrote: >=20 > >>>>> +# @filename: #optional unix or inet path. The format is: > >>>>> +# unix: nbd+unix:///export?socket=3Dpath or > >>>>> +# nbd:unix:path:exportname=3Dexport > >>>>> +# inet: nbd[+tcp]://host[:port]/export or > >>>>> +# nbd:host[:port]:exportname=3Dexport > >>> >=20 > > Since there's an either/or, the complex QAPI type should be a union. > >=20 > >>> { 'enum': 'NBDTransport', 'data': ['unix', 'tcp', 'udp'] } > >> > >> NBD only uses tcp, it doesn't support udp. >=20 > Fair enough. >=20 > >> > >>> { 'union': 'BlockdevOptionsNBD', > >>> 'base': { 'transport': 'NBDTransport', 'export': 'str' }, > >>> 'discriminator': 'transport', > >>> 'data': { 'unix': 'NBDUnix', 'tcp': 'NBDInet', 'udp': 'NBDInet' } } > >>> { 'struct': 'NBDUnix', 'data': { 'socket': 'str' } } > >> > >> unix socket needs a path, and I think we can use UnixSocketAddress her= e. >=20 > Sure, if that works, you could do 'unix':'UnixSocketAddress' instead of > inventing 'NBDUnix'. >=20 > >=20 > > Yes, we should try to reuse common types like SocketAddress, > > InetSocketAddress, UnixSocketAddress. >=20 > Well, we've already questioned whether 'InetSocketAddress' needs to be > fixed to be separate from a socket range, but it can be a separate fix. >=20 > >=20 > > Perhaps it could be as simple as > >=20 > > { 'struct': 'BlockdevOptionsNBD', > > 'data': { 'addr: 'SocketAddress', 'export': 'str' } } > >=20 > > Eric, what do you think? >=20 > It has more nesting on the wire, but should work. That is, to express > "nbd+unix:///export?socket=3Dpath", the QMP would be: >=20 > { "export":"export", "addr":{ "type":"unix", "data":{ "path": "str"}}} >=20 > instead of a nicer: >=20 > { "export":"export", "type":"unix", "path":"str" } >=20 > but the advantage of working now rather than waiting on qapi fixes in > the pipeline has its benefit. Both patches are for 2.5 anyway. Is the benefit of getting this in before the QAPI series really that big that we should go with an ugly syntax? > There's also the question of how to handle 'fd', if NBD can't reuse an > existing fd but must be given a unix socket filename or tcp host/port > destination. Documenting that we reject a combination may be okay, > except that it is harder to introspect later if the combination is no > longer rejected because we later add support. How about implementing fd suppor instead? Kevin --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV+ByFAAoJEH8JsnLIjy/W5FAQAK5jMznGONwerjKhP4CznFoF JGpP3G7r8sEDaup0XoS+fwkiajcjJ55w8YhM0eytzypVJWzOb//jZ8wQn2nEVWEf 63qP5m2rv9OV/FEI2X4no8YXXz0Pao2D7g42rMZCW87keTaNK2j7kcZKoDEOIzRo hogCXx60RR0C2dmA7PpG/F5zIxoqcNOsigIzoniQXMzPnKEQIe1mZcGoExxvhnwo mMaQ28HVL5k3fvPqLJ4HUTzy7I5o/4p9Kfcch/fv4dSlZdtVtyjTfI937GcB7mYu Ih8saZ+qtAqbs+/hPp9oHTUEqPUxQf4QHoFQ5ShCgWsPAvSsaraCiNBnQPXevuRt 7KT1L81lcJLxVg8//6bzNFUerPtOsJp4USnKWmU5KGibYQqy3X/JUt9ZLDU+BJ6N kPDzk7eAi3+Smf1MnyUR/TKdQNdAkW9UuSx5iqvDfYgWjfp/hQWzWrsd1yUbV/3F fSY7wsuLQDiyUT7Td92CiIQI5x24mvPnJy4m3+iI49uDxWHjwN5JiaMKzQ6H6Xo9 8RIzSxovIxMXMrW73YT6L20CfywltSqo3wKlAScNgj7df/y1PjxRq6zm1bq0kUSc 5q/dE5jyezKqLhntn43AM9m5tafMfETM5QsI9WpJnbe0ajSLL3vCl7R8OZ7QPmNg Oaia0SIu4lB4fNWre6Pq =QoY4 -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--