On Thu 03 May 2018 02:22:41 PM CEST, Kevin Wolf wrote: > Am 02.05.2018 um 16:12 hat Max Reitz geschrieben: >> On 2018-05-02 15:07, Alberto Garcia wrote: >> > Were the (more or less) exact requirements of QMP blockdev-reopen >> > discussed? How is it different from qemu-io's "reopen" command? What are >> > the options that you can and can not change? >> >> I can't quite remember, I'm afraid. I think it was supposed to be >> pretty much qemu-io's reopen (so just bdrv_reopen()). I suppose you >> cannot change the driver (obviously) or probably the node name, because >> either would result in the node being replaced by a completely new one. >> >> Other than that, it probably depends on what the block driver supports, >> but ideally you should be able to change everything. > > Honestly the design of bdrv_reopen() is quite broken because of the way > it tries to maintain old options if they aren't specified, and guesses > what you might mean when you add flags to the mix. The exact semantics > are quite complicated and I'd rather avoid them in a stable API. > > A clean QMP command would probably apply the same defaults as > blockdev-add, so you just get to specify the full options again.
Ok, so the end result would be more or less equivalent to "open the new block device with blockdev-add and the user-specified options, then replace the old one with the new one", but implemented with reopen instead of open + replace. Berto
