On 07/19/2017 12:32 PM, Anton Ivanov wrote: > > > On 19/07/17 15:40, Eric Blake wrote: >> On 07/18/2017 12:08 PM, anton.iva...@cambridgegreys.com wrote: >>> From: Anton Ivanov <anton.iva...@cambridgegreys.com> >>> >>> This adds GRETAP support to the unified socket driver. >>>
>>> +#
>>> +# @ipv6: force the use of ipv6
>> This doesn't quite match what we do with other sockets (where we have
>> both ipv4 and ipv6 booleans to allow IPv4-only, IPv6-only, or both). Is
>> this something where we can reuse InetSocketAddress instead of inventing
>> yet another way of doing things?
>>
>> Then again, it does match what NetdevL2TPv3Options did :(
>
> I just reviewed this again.
>
> I do not think we can today. This is the declaration:
>
> ##
> { 'struct': 'InetSocketAddressBase',
> 'data': {
> 'host': 'str',
> 'port': 'str' } }
>
> ##
>
> If I read this right port is mandatory, correct?
Okay, so it sounds like reusing InetSocket directly may not be possible.
But there's still the interface question of whether we want dual 'ipv4'
and 'ipv6' switches to allow finer-grain control over which (or both)
families to be used.
>
> We may be able to do it if the port portion if InetSocketAddress becomes
> optional. There is no such thing as port for the protocols which use the
> raw families.
We can always create a new QAPI type that expresses only the fields we
need; I don't think InetSocketAddress should be changed to have an
optional port just for your code additions.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
