qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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