Paolo Bonzini <pbonz...@redhat.com> writes: > On 14/05/20 10:56, Daniel P. Berrangé wrote: >> On Thu, May 14, 2020 at 10:09:21AM +0200, Paolo Bonzini wrote: >>> IMHO configuration files are in general a failed experiment. In >>> practice, they do not add much value over just a shell script because >>> they don't allow configuring all QEMU options, they are very much fixed >>> (by their nature). I think it's more or less agreed that they are not >>> solving any problem for higher-level management stacks as well; those >>> would prefer to configure the VM via QMP or another API. >>> >>> So, any objections to deprecating -readconfig and -writeconfig? >> >> Libvirt would like to have a config file for QEMU, but it would have >> to be one that actually covers all the config options QEMU supports, >> and ideally using a data format in common with that used for runtime >> changes. So for libvirt's needs the current readconfig is entirely >> useless. > > Yes, this is what I was thinking about. > >> For a less general purpose mgmt app, that targets some specific use >> cases I could imagine people might have used readconfig. [...] >> If we deprecate them, the only alternative users have right now is >> to go back to passing CLI args. [...] We'd be deciding to kill the >> feature with no direct replacement, even though it is potentially >> useful in some limited scenarios. >> >> If we have a general strategy to eliminate QemuOpts and move entirely >> to QAPI based config, then I can see -readcofig/-writeconfig may be >> creating a burden of back compatibility on maintainers. > > I don't see QemuOpts going away anytime soon, but I do see more QMP/QAPI > and less command line in the future as far as management tools are > concerned. QemuOpts and HMP will remain for direct usage, for the > foreseeable future.
I'd prefer not to have two separate configuration infrastructures. > So I guess we can keep -readconfig but deprecate, or even remove, > -writeconfig. Deprecate both as stable interfaces, remove neither.
