From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1x3T-0006gg-Ek for qemu-devel@nongnu.org; Wed, 02 Nov 2016 11:02:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1x3N-0006Zl-Il for qemu-devel@nongnu.org; Wed, 02 Nov 2016 11:02:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46370) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c1x3N-0006Yw-C2 for qemu-devel@nongnu.org; Wed, 02 Nov 2016 11:02:13 -0400 Date: Wed, 2 Nov 2016 16:02:07 +0100 From: Kevin Wolf Message-ID: <20161102150207.GI6182@noname.redhat.com> References: <1477640667-4775-1-git-send-email-ashish.mittal@veritas.com> <7179b840-077d-a06f-e2ab-4da711029cfd@redhat.com> <20161031105509.GC2668@redhat.com> <20161102095738.GA6182@noname.redhat.com> <1be58a5d-3690-a9b2-d395-01c72ba64e78@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <1be58a5d-3690-a9b2-d395-01c72ba64e78@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3] block/vxhs: Add Veritas HyperScale VxHS block device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: ashish mittal , "Daniel P. Berrange" , qemu-devel@nongnu.org, Paolo Bonzini , Markus Armbruster , Jeff Cody , famz@redhat.com, Ashish Mittal , Stefan Hajnoczi , Rakesh Ranjan , Buddhi.Madhav@veritas.com, Ketan.Nilangekar@veritas.com, Abhijit.Dey@veritas.com, Venkatesha.Mg@veritas.com --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 02.11.2016 um 15:13 hat Eric Blake geschrieben: > On 11/02/2016 04:57 AM, Kevin Wolf wrote: > >>> IMHO it should allow use of UNIX sockets, as its possible to have > >>> SSH setup a tunnel to a IP server, and expose the endpoint via a > >>> UNIX socket. So even if your reference server only supports IPv4, > >>> users can conceivably connect with any sockets protocol. > >>> > >> > >> This is not a use-case that we have in mind right now, but a very fair > >> point! Kind of like accessing the audio/video streams remotely from my > >> Raspberry Pi over ssh. Is it OK if we target this in a future patch > >> after proper review/testing? > >=20 > > No, going from InetSocketAddress to SocketAddress changes the API in an > > incompatible way (previously working blockdev-add commands would stop > > working), so we must decide now before the API is introduced. >=20 > Going from InetSocketAddress to SocketAddress is a pain because > SocketAddress is a 'simple union' (which really means extra nesting on > the wire). I'd really rather that blockdev-add move towards the > GlusterServer style of a 'flat union', which CAN be done in a > backwards-compatible manner. However, the actual networking functions in qemu take a SocketAddress or InetSocketAddress pointer, not whatever else we would invent for the block layer API, so we would have to add conversion functions. The whole point of using these types was to have a consistent API with other subsystems. :-/ gluster and NFS can use something different only because they don't use the qemu networking functions, but whatever limited set of options their external library supports. > [side note: Uggh - why did we let gluster go into 2.7 with 'tcp' instead > of 'inet' :( I'm wondering if we want gluster in 2.8 to recognize 'inet' > as a synonym for 'tcp'; I could propose a patch if we think it is > worthwhile] Fine with me. Remove 'tcp' from the schema then as long as blockdev-add is still experimental. We only need to keep it working on the command line. Kevin --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYGf/vAAoJEH8JsnLIjy/WWOoQALG2YgcEussL+xZFwGADX7QQ vtVr1sJmRzF114/tZIeh8QMiRqwUL+X4gn8dti3Cjxtx1mP3i5ZCYBWwNsbKiegc RBB3HfsUNCLxVu94VKSGd7u7bK1ejFGNWprEjJgw7DQt1mQRAm3Gz89z8qya9WY1 InxmctzX2sjMQLw++dRBwnmNv+ZwCostbmI+yjg7ioIrCF+EGDpdjX2MUICfua73 QfqHFhf8fR1bH1EyqdQK8ZqByMg/fLk13lSvbwfY17DjBZ11p6GiWHtqZx7M/eKw JSsrPFtsZucYho7r8Gsj/gQdNEpIHtzGzwvvs+Eulo44eYdChHFhf+1vmo6EcSqe FGF9RPGeUg7dAHNlQFaJ2WxltXQgiXMINbTKEl+iWbQfzx3WOdvFxwrxNZEwEOWf 5+luJK0RGSOQcFOAJkge2ga9aHvS4bEHIfXMy9QgCJbr/2mGjTIw5lmXRg0EYfIY HR2sBhrgpa7bTOrGbH1jUKylfpzr9oe7luf+CbcYACRbj1rsxfBm4iFF92BZh3Qv jpiuLjHbMrb7ZybJevyX9gITSU7i0upa4nYesWGoc2ZmXUqcZn3OrmQvQix+qBQ1 TZLDvNfLEeSh+KKy3bgPN/dFrWy7ztojOfK4sl4up6iyFqXt+G18e2fm3DO+ZcaI SlQXpR+tVjsE4sytswvy =eFx4 -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g--