On 09/14/2015 11:47 PM, Eric Blake wrote:
> On 09/14/2015 08:27 AM, Markus Armbruster wrote:
>> Wen Congyang <we...@cn.fujitsu.com> writes:
>>
>>> The NBD driver needs: filename, path or (host, port, exportname).
>>> It checks which key exists and decides use unix or inet socket.
>>> It doesn't recognize the key type, so we can't use union, and
>>> can't reuse InetSocketAddress.
>>>
>>> Signed-off-by: Wen Congyang <we...@cn.fujitsu.com>
>>> Signed-off-by: zhanghailiang <zhang.zhanghaili...@huawei.com>
>>> Signed-off-by: Gonglei <arei.gong...@huawei.com>
>>> ---
>>> qapi/block-core.json | 42 ++++++++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 40 insertions(+), 2 deletions(-)
>>>
>
>>> ##
>>> +# @BlockdevOptionsNBD
>>> +#
>>> +# Driver specific block device options for NBD
>>> +#
>>> +# @filename: #optional unix or inet path. The format is:
>>> +# unix: nbd+unix:///export?socket=path or
>>> +# nbd:unix:path:exportname=export
>>> +# inet: nbd[+tcp]://host[:port]/export or
>>> +# nbd:host[:port]:exportname=export
>
> Yuck. You are passing structured data through a single 'str', when you
> SHOULD be passing it through structured JSON. Just because we have a
> filename shorthand for convenience does NOT mean that we want to expose
> that convenience in QMP. Instead, we really want the breakdown of the
> pieces (here, using abbreviated syntax of an inline base, since there
> are pending qapi patches that will allow it):
Do you mean that: there is no need to support filename?
>
> { 'enum': 'NBDTransport', 'data': ['unix', 'tcp', 'udp'] }
NBD only uses tcp, it doesn't support udp.
> { '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 here.
> { 'struct': 'NBDInet', 'data': { 'host': 'str', '*port': 'int',
> '*ipv4': 'bool', '*ipv6': 'bool' } }
Thanks for the above, and I will try it.
>
>
>> I'm afraid this doesn't address Eric's review of your v2.
>
> Agreed; we still don't have the right interface.
>
>
>> Eric further observed that support for the nbd+unix transport was
>> missing, and suggested to have a union type combining the various
>> transports.
>
> And I just spelled out above what that should look like.
>
>>
>> If we decide separate types for single port and port ranges aren't
>> worthwhile, you can simply use SocketAddress where your v2 used
>> InetSocketAddress.
>
> I'm not sure if my 'NBDInet' above makes any more sense than reusing
> 'SocketAddress' (and if we do reuse 'SocketAddress', we have the further
> question of whether to split out socket ranges as a separate type so
> that SocketAddress becomes a single-port identity).
>
>>
>> Eric, how strongly do you feel about separating the two?
>
> I'm more worried about properly using a union type to represent unix vs.
> tcp, and less worried about SocketAddress vs. range types vs creating a
> new type (although in the long run, fixing ranges to be in a properly
> named type rather than re-inventing the struct across multiple
> transports is a good goal). But you are quite correct that I do not
> like the v3 proposal, because it encodes far too much information into a
> single '*filename':'str', which is not the qapi way.
>
