From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbVyM-0005Xc-Ij for qemu-devel@nongnu.org; Mon, 14 Sep 2015 11:47:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbVyL-0004D1-C7 for qemu-devel@nongnu.org; Mon, 14 Sep 2015 11:47:14 -0400 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> From: Eric Blake Message-ID: <55F6EBF5.2090101@redhat.com> Date: Mon, 14 Sep 2015 09:47:01 -0600 MIME-Version: 1.0 In-Reply-To: <87r3m1krdl.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wvCdGoTUMn1tRDiGrAbI8Jk13QuakEEvN" 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: Markus Armbruster , Wen Congyang Cc: Kevin Wolf , Alberto Garcia , zhanghailiang , qemu block , Jiang Yunhong , Dong Eddie , qemu devel , "Dr. David Alan Gilbert" , Gonglei , Stefan Hajnoczi , Yang Hongyang This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wvCdGoTUMn1tRDiGrAbI8Jk13QuakEEvN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/14/2015 08:27 AM, Markus Armbruster wrote: > Wen Congyang writes: >=20 >> The NBD driver needs: filename, path or (host, port, exportname). >> It checks which key exists and decides use unix or inet socket. >> It doesn't recognize the key type, so we can't use union, and >> can't reuse InetSocketAddress. >> >> Signed-off-by: Wen Congyang >> Signed-off-by: zhanghailiang >> Signed-off-by: Gonglei >> --- >> qapi/block-core.json | 42 ++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 40 insertions(+), 2 deletions(-) >> >> ## >> +# @BlockdevOptionsNBD >> +# >> +# Driver specific block device options for NBD >> +# >> +# @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 Yuck. You are passing structured data through a single 'str', when you SHOULD be passing it through structured JSON. Just because we have a filename shorthand for convenience does NOT mean that we want to expose that convenience in QMP. Instead, we really want the breakdown of the pieces (here, using abbreviated syntax of an inline base, since there are pending qapi patches that will allow it): { 'enum': 'NBDTransport', 'data': ['unix', 'tcp', 'udp'] } { 'union': 'BlockdevOptionsNBD', 'base': { 'transport': 'NBDTransport', 'export': 'str' }, 'discriminator': 'transport', 'data': { 'unix': 'NBDUnix', 'tcp': 'NBDInet', 'udp': 'NBDInet' } } { 'struct': 'NBDUnix', 'data': { 'socket': 'str' } } { 'struct': 'NBDInet', 'data': { 'host': 'str', '*port': 'int', '*ipv4': 'bool', '*ipv6': 'bool' } } > I'm afraid this doesn't address Eric's review of your v2. Agreed; we still don't have the right interface. > Eric further observed that support for the nbd+unix transport was > missing, and suggested to have a union type combining the various > transports. And I just spelled out above what that should look like. >=20 > If we decide separate types for single port and port ranges aren't > worthwhile, you can simply use SocketAddress where your v2 used > InetSocketAddress. I'm not sure if my 'NBDInet' above makes any more sense than reusing 'SocketAddress' (and if we do reuse 'SocketAddress', we have the further question of whether to split out socket ranges as a separate type so that SocketAddress becomes a single-port identity). >=20 > Eric, how strongly do you feel about separating the two? I'm more worried about properly using a union type to represent unix vs. tcp, and less worried about SocketAddress vs. range types vs creating a new type (although in the long run, fixing ranges to be in a properly named type rather than re-inventing the struct across multiple transports is a good goal). But you are quite correct that I do not like the v3 proposal, because it encodes far too much information into a single '*filename':'str', which is not the qapi way. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --wvCdGoTUMn1tRDiGrAbI8Jk13QuakEEvN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJV9uv1AAoJEKeha0olJ0Nqf1oIAJwLS2O6SFKSvoCyoZGEFa+O 3j59tPLxWjNkp3BLPJA9SZCbaBTULEbwHGybYf+ftnGvUiQlhMNeEtG4u+Ow1PGs aGunrTxFLW9Pe5sot2EYNlTcN7XUsZQgJpQrM/9iK46GJpHioNsmKyw4wfT1x50y zjFy6Qjg9of/aRMHEq5M6IqNrcn0yszXSzC4kcQq/eXhrjtA0k9RuFjdTbBxNR6n GtWFo9rQaq8hUh8Rqea/Et82KBb3HpfmJuvyImoWBrX+nOTt55yzz6PuQz65etp8 Lf6UjqixAZbPswp9nURv8bW/YN/4hH/Hb++LXe6vzFjtW6Ie6Lu3mIWjijEU/Fo= =roTC -----END PGP SIGNATURE----- --wvCdGoTUMn1tRDiGrAbI8Jk13QuakEEvN--