qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] block/nfs: Fine grained runtime options in


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] block/nfs: Fine grained runtime options in nfs
Date: Tue, 18 Oct 2016 08:49:53 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 10/18/2016 08:33 AM, Kevin Wolf wrote:

>> I have successfully converted NFS block driver to use this set of
>> runtime opts which I think is the required condition to add
>> blockdev-add compatibility later. Also, since I do not have 'port' as
>> a runtime option, I can directly add blockdev-add compatibility after
>> this through qapi/block-core.json and will not have to go through the
>> tricky method we are implementing for NBD and SSH as there will be no
>> use of InetSocketAddress. Right?
> 
> Yes, InetSocketAddress is what makes things a bit tricky, and it doesn't
> seem to be useful with the API we get from libnfs, so just directly
> taking a host name should be okay. Then this one should be easier than
> SSH.
> 
> Eric, do you agree, or do you think we should take into account that
> libnfs might be extended one day to work on any socket?

Ideally, we want the valid JSON for ssh to be a subset of the valid JSON
for either InetSocketAddress, or for a flat counterpart (what we did for
gluster).  I kind of like the flat counterpart idea.  Yes, that probably
means we need to create a new QAPI type (comparable to the existing
types, but omitting port), rather than being able to reuse one; but as
long as the parameters are spelled the same, backwards-compatibility
states that we can later add fields, and that any two structs with
identical fields can be merged into one struct without breaking
backwards compatibility.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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