On Tue 22 Jan 2019 09:15:25 AM CET, Vladimir Sementsov-Ogievskiy wrote: >>> a) Some options cannot be changed (most drivers don't allow that, in >>> fact). >>> b) If an option is missing, it should be reset to its default value >>> (rather than keeping its previous value). >> >> Could we use QAPI alternate types where we could state that: >> >> "option":"new" - set the option >> "option":null - reset the option to its default >> omit option - leave the option unchanged >> >> basically, making each of the options an Alternate with JSON null, so >> that a request to reset to the default becomes an explicit action? > > +1 > > Sorry, I missed the previous discussion. What is the reason to reset > option to default if it missed? It looks more common to not touch > things which are not asked to.
The idea is to have a command that works like blockdev-add. If you pass a set of options to x-blockdev-reopen then the end result should be similar to what you would get if you had used blockdev-add. > Also, should we consider an option which may be changed during > life-cycle of a device not by user request to change it? If yes, it > should be safer to not reset it. Do you have any example in mind? > And here: if we are going to reset to default for not listed options, > than just not listing "backing" should remove it (as default is null, > obviously), and we don't need this special "null" parameter. This is a bit trickier: the default for 'backing' is not to omit the backing file, but to open the one that is specified in the image metadata. $ qemu-img create -f qcow2 base.qcow2 1M $ qemu-img create -f qcow2 -b base.qcow2 active.qcow2 If you open active.qcow2 with blockdev-add then base.qcow2 is opened as its backing file, and the only way to prevent that is to specify a different backing file or null if you don't want to open any. For x-blockdev-reopen we want to keep the same behavior as much as possible, but instead of opening base.qcow2 if 'backing' is missing we force the user to specify that option. > Moreover, backing is an example of an option I mentioned, it > definitely may change after block-stream for example, so resetting to > default is unsafe, and user will have to carefully set backing on > reopen (not tha backing, that was used with first blockdev-add, but > backing which we have after block-stream) Exactly. Since opening the default backing file is not something that we want to do during a reopen operation we don't allow leaving that option out. Berto
