qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/4] sockets: add AF_VSOCK support


From: Michael Roth
Subject: Re: [Qemu-devel] [PATCH 3/4] sockets: add AF_VSOCK support
Date: Fri, 07 Oct 2016 11:42:35 -0500
User-agent: alot/0.3.6

Quoting Stefan Hajnoczi (2016-10-06 11:40:17)
> Add the AF_VSOCK address family so that qemu-ga will be able to use
> virtio-vsock.
> 
> The AF_VSOCK address family uses <cid, port> address tuples.  The cid is
> the unique identifier comparable to an IP address.  AF_VSOCK does not
> use name resolution so it's seasy to convert between struct sockaddr_vm
> and strings.
> 
> This patch defines a VsockSocketAddress instead of trying to piggy-back
> on InetSocketAddress.  This is cleaner in the long run since it avoids
> lots of IPv4 vs IPv6 vs vsock special casing.
> 
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
>  qapi-schema.json    |  23 +++++-
>  util/qemu-sockets.c | 222 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 244 insertions(+), 1 deletion(-)
> 
> diff --git a/qapi-schema.json b/qapi-schema.json
> index c3dcf11..8864a96 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -987,12 +987,14 @@
>  #
>  # @unix: unix socket
>  #
> +# @vsock: vsock family (since 2.8)
> +#
>  # @unknown: otherwise
>  #
>  # Since: 2.1
>  ##
>  { 'enum': 'NetworkAddressFamily',
> -  'data': [ 'ipv4', 'ipv6', 'unix', 'unknown' ] }
> +  'data': [ 'ipv4', 'ipv6', 'unix', 'vsock', 'unknown' ] }
> 
>  ##
>  # @VncBasicInfo
> @@ -3017,6 +3019,24 @@
>      'path': 'str' } }
> 
>  ##
> +# @VsockSocketAddress
> +#
> +# Captures a socket address in the vsock namespace.
> +#
> +# @cid: unique host identifier
> +# @port: port
> +#
> +# Note that string types are used to allow for possible future hostname or
> +# service resolution support.
> +#
> +# Since 2.8
> +##
> +{ 'struct': 'VsockSocketAddress',
> +  'data': {
> +    'cid': 'str',
> +    'port': 'str' } }

Is there any reason to not define these as uint32_t? Not sure if there
are other reasons for this, but if it's just for consistency with how
Inet is handled, the code seems to do straight atoi()<->printf("%d") to
covert between numerical and string representation so it doesn't seem
like we need to account for any differences between command-line and
internal representation in sockaddr_vm.




reply via email to

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