[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Question nbd_refresh_filename()
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] Question nbd_refresh_filename() |
Date: |
Fri, 24 Mar 2017 18:48:44 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 24.03.2017 um 16:47 hat Stefan Hajnoczi geschrieben:
> On Thu, Mar 23, 2017 at 05:48:48PM +0100, Markus Armbruster wrote:
> > BlockdevOptionsNbd has a member SocketAddress, and nbd_config() doesn't
> > restrict variants. Thus, all four SOCKET_ADDRESS_KIND_ can occur.
> >
> > Now have a look at nbd_refresh_filename(). s->saddr->type is If
> > SOCKET_ADDRESS_KIND_VSOCK or SOCKET_ADDRESS_KIND_FD, then @host, @port
> > and @path all remain null, and bs->exact_filename[] is not touched.
> >
> > Does this work as intended?
>
> NDB over AF_VSOCK has not been tested. I would expect it to fail
> earlier than nbd_refresh_filename().
Why would that be? Do the socket creation helper functions not support
vsock yet?
> It's certainly possible to come up with the host=,port= for AF_VSOCK.
>
> Not sure about file descriptor passing. Either we could getsockaddr()
> and print out the host=,port= or path= (depending on the address
> family), or we could use some syntax for referring to the file
> descriptor.
The point of .bdrv_refresh_filename is to provide a "nicer" filename for
humans, but it still needs to be a valid input. We do accept URLs as a
convenience feature for NBD connections over TCP and Unix domain
sockets, so we create a filename for those. For everything else, we
require individual options rather than a URL and should therefore not
create a filename. The block layer creates a json: description then.
Kevin