qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal: deprecate -readconfig/-writeconfig


From: Paolo Bonzini
Subject: Re: proposal: deprecate -readconfig/-writeconfig
Date: Thu, 14 May 2020 17:51:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 14/05/20 17:34, Daniel P. Berrangé wrote:
> Yeah, the key thing is that you really want to be able to provide the
> whole initial config in one go as an atomic action. I don't want to
> issue 100 individual QMP commands to load each initial device.

Why?  I think if we do something like the qemu-vm-$TARGET that you
propose below, there's absolutely no difference between the two.

Then you'd have a

qemu-run /some/file.yaml

(notice the lack of $TARGET) that takes care of starting the VM.

> I tend to think we'd be better served by focusing on introducing a new set
> of binaries,  qemu-vm-$TARGET, which exclusively use a new config syntax,
> free of any legacy baggage present in qemu-system-$TARGET.
> 
> Work on qemu-vm-$TARGET will involve refactoring, and that will certainly
> risk causing bugs in qemu-system-$TARGET. The premise though is that this
> risk is lower, than if we tried to retrofit a new config syuntax directly
> into qemu-system-$TARGET.
> 
> In particular I think it is basically impossible to do any meaningful
> changes in the main() method of softmmu/vl.c, due to the fragile ordering
> for creation of various different devices/backends, and its interaction
> with the argv parsing. By using a new qemu-vm-$TARGET we can have a new
> softmmu/vm.c, instead of vl.c. We'll still likely need to modify parts of
> vl.c to use new/changed API calls, but that's less distruptive, as we
> can leave the crazy logic for ordering of device creation untouched.

Agreed.

Paolo




reply via email to

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