[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] qapi: Allow blockdev-add for NBD
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] qapi: Allow blockdev-add for NBD |
Date: |
Thu, 4 Feb 2016 14:08:23 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 03.02.2016 um 18:06 hat Daniel P. Berrange geschrieben:
> On Wed, Feb 03, 2016 at 05:33:16PM +0100, Max Reitz wrote:
> > We have to introduce a new object (BlockdevOptionsNbd) for several
> > reasons:
> > - Neither of InetSocketAddress nor UnixSocketAddress alone is
> > sufficient, because both are supported
> > - We cannot use SocketAddress because NBD does not support an fd,
> > and because it is not a flat union which BlockdevOptionsNbd is
>
> With my patch series that converts NBD to use QIOChannel, all the
> entry points for client & server *do* take a SocketAddress struct
> to provide address info. So internally the code does in fact allow
> use of an FD, if there were a way to specify it a the QAPI level...
>
> eg see
>
> https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04159.html
That's patch 1 of a series that has a few more dependencies. Can the
patch be applied without the rest of the series (and without the
dependencies) so that we don't have to wait for a very long time with
Max's patches?
> > - We cannot use a flat union of InetSocketAddress and
> > UnixSocketAddress because we would need some kind of discriminator
> > which we do not have; we could inline the UnixSocketAddress as a
> > string and then make it an 'alternate' type instead of a union, but
> > this will not work either, because:
> > - InetSocketAddress itself is not suitable for NBD because the port is
> > not optional (which it is for NBD) and because it offers more options
> > (like choosing between ipv4 and ipv6) which NBD does not support.
>
> The *should* support ipv4 and ipv6 options for NBD. We should also make
> the port optional in the SocketAddress struct - I tried to do that previously
> but my patch was flawed, but we should revisit this.
>
> So IMHO all the things you list above are reasons *for* using SocketAddress
> and not re-inventing it poorly with explicit host + port fields.
Agreed. Anything in SocketAddress that isn't supported is either a bug
or a missing feature.
Kevin
- [Qemu-devel] [PATCH 1/2] block/nbd: Reject port parameter without host, (continued)