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
