On Wed, Dec 19, 2018 at 11:50:38AM -0500, Michael S. Tsirkin wrote: > On Wed, Dec 19, 2018 at 04:01:02PM +0000, Daniel P. Berrangé wrote: > > On Wed, Dec 19, 2018 at 10:55:09AM -0500, Michael S. Tsirkin wrote: > > > On Tue, Dec 18, 2018 at 04:09:19PM +0000, Daniel P. Berrangé wrote: > > > > On Tue, Dec 18, 2018 at 11:02:46AM -0500, Michael S. Tsirkin wrote: > > > > > On Tue, Dec 18, 2018 at 03:25:20PM +0000, Daniel P. Berrangé wrote: > > > > > > On Tue, Dec 18, 2018 at 04:24:26PM +0400, Marc-André Lureau wrote: > > > > > > > Hi > > > > > > > > > > > > > > On Tue, Dec 18, 2018 at 2:01 PM <elohi...@gmail.com> wrote: > > > > > > > > > > > > > > > > From: Xie Yongji <xieyon...@baidu.com> > > > > > > > > > > > > > > > > New option "disconnected" is added to init the chardev socket > > > > > > > > in disconnected state. Then we can use > > > > > > > > qemu_chr_fe_wait_connected() > > > > > > > > to connect when necessary. Now it would be used for unix domain > > > > > > > > socket of vhost-user-blk device to support reconnect. > > > > > > > > > > > > > > What difference does that make if you wait for connection in > > > > > > > qemu_chr_fe_wait_connected(), or during chardev setup? > > > > > > > > > > > > > > "disconnected" is misleading, would it be possible to reuse > > > > > > > "wait/nowait" instead? > > > > > > > > > > > > Currently we default to doing a blocking connect in foreground, > > > > > > except if reconnect is non-zero, in which case we do a connect > > > > > > async in the background. This "disconnected" proposal effectively > > > > > > does a blocking connect, but delayed to later in startup. > > > > > > > > > > > > IOW, this could already be achieved if "reconnect" were set to > > > > > > non-zero. If the usage doesn't want reconnect though, I tend > > > > > > to agree that we should use the exisiting wait/nowait options > > > > > > to let it be controlled. I don't see that this "disconnected" > > > > > > option gives a compelling benefit over using wait/nowait. > > > > > > > > > > So the tricky thing is that we can not expose the > > > > > device to guest until we get a connection and can query > > > > > it for the first time. After that is completed, > > > > > we can reasonably support disconnected operation at least for net. > > > > > > > > The device code would still use qemu_chr_fe_wait_connected() in my > > > > proposal, > > > > so that its no different to the situation with the proposed > > > > "disconnected" > > > > flag. > > > > > > > > Regards, > > > > Daniel > > > > > > I guess so, but wouldn't it be confusing to users that one says > > > "nowait" and qemu still waits for a connection and does not > > > run the VM? That's different from how nowait behaves normally. > > > > Well "nowait" is only referring to the chardev behaviour which is > > still an accurate description. > > man page seems to say > > nowait specifies that QEMU should not block waiting > for a client to connect to a listening socket. > > if we do wait for a client to connect then how is it accurate?
Well the manpage needs to be clarified that this applies to the initialization of the chardev. What a downstream objet/device does with the chardev is outside the scope of chardev config options. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
