qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3] block/vxhs: Add Veritas HyperScale VxHS bloc


From: ashish mittal
Subject: Re: [Qemu-devel] [PATCH v3] block/vxhs: Add Veritas HyperScale VxHS block device support
Date: Wed, 2 Nov 2016 09:41:00 -0700

On Wed, Nov 2, 2016 at 7:13 AM, Eric Blake <address@hidden> wrote:
> 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?
>>
>> 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.
>
> 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.  Or, with examples:
>
> InetServer alone:
> { "host": "foo", "port": "1000" }
>
> SocketAddress:
> { "type": "inet", "data": { "host": "foo", "port": "1000" } }
>
> GlusterServer:
> { "type": "tcp", "host": "foo", "port": "1000" }
>
> For comparison, we wrote NFSServer with an eye towards possible
> expansion into a flat version (more like GlusterServer than SocketAddress).
>
> NFSServer:
> { "type": "inet", "host": "foo" }
>

So do I still need to add the UNIX sockets (go from InetSocketAddress
to SocketAddress)?
If yes, would it be OK to implement just the interface right now (not
the backend) and issue a message like "UNIX sockets are not yet
supported"?

>
> [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]
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]