From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbqC9-0000Gg-DW for qemu-devel@nongnu.org; Tue, 15 Sep 2015 09:22:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zbptu-0003iP-EF for qemu-devel@nongnu.org; Tue, 15 Sep 2015 09:04:04 -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> <55F6EBF5.2090101@redhat.com> <55F776CC.3050601@cn.fujitsu.com> <87fv2g876a.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55F8172B.5020209@redhat.com> Date: Tue, 15 Sep 2015 07:03:39 -0600 MIME-Version: 1.0 In-Reply-To: <87fv2g876a.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fo4pLkHCqPRmFSKvehQB2PL0k9oXNCrIf" 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) --fo4pLkHCqPRmFSKvehQB2PL0k9oXNCrIf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/15/2015 01:37 AM, Markus Armbruster wrote: >>>>> +# @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 >>> > 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. Fair enough. >> >>> { '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. Sure, if that works, you could do 'unix':'UnixSocketAddress' instead of inventing 'NBDUnix'. >=20 > Yes, we should try to reuse common types like SocketAddress, > InetSocketAddress, UnixSocketAddress. 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 > Perhaps it could be as simple as >=20 > { 'struct': 'BlockdevOptionsNBD', > 'data': { 'addr: 'SocketAddress', 'export': 'str' } } >=20 > Eric, what do you think? It has more nesting on the wire, but should work. That is, to express "nbd+unix:///export?socket=3Dpath", the QMP would be: { "export":"export", "addr":{ "type":"unix", "data":{ "path": "str"}}} instead of a nicer: { "export":"export", "type":"unix", "path":"str" } but the advantage of working now rather than waiting on qapi fixes in the pipeline has its benefit. 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fo4pLkHCqPRmFSKvehQB2PL0k9oXNCrIf 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/ iQEcBAEBCAAGBQJV+BcrAAoJEKeha0olJ0NqtwAIAKGjfvHge9IGjE8jDpbe6aiA 5UER7HsfJ0CFVUS+7+S8BGaQ2OFzco6YeF4uCDi6NFBMk799tCBzeQ6rwlQTi42P 2Q1l08NMgpy0ec2GdLIQQDidD2zQc19qyTcVwAQ1WsDBxtNB6cPyLmFlWV5PvZwe KQ1W2YHBJ6X5Bs5WWpHL/m0SOCScyYd6fV2FV7WsMXGAoVVnA+mBsJDdCM8wH+AN 6LGbuMx5jN2l+U22zHcAmRMpBo9Of5Ls1j4HAybIoW48ptM5eUjHX7nXhdYjVEop 5BA0ObG1n8yaG/hrC6AwNfMjznEOLlAtQZ4283gRVfSnNWdija9VGmknWPAznqE= =+X/q -----END PGP SIGNATURE----- --fo4pLkHCqPRmFSKvehQB2PL0k9oXNCrIf--