On Thu, Jan 22, 2026 at 12:47:47PM -0300, Fabiano Rosas wrote: > One question I have is what exactly gets (eventually) removed from QEMU > and what benefits we expect from it. Is it the entire "manual" > interaction that's undesirable? Or just that to maintain HMP there is a > certain amount of duplication? Or even the less-than-perfect > readline/completion aspects?
Over time we've been gradually separating our human targetted code from our machine targetted code, whether that's command line argument parsing, or monitor parsing. Maintaining two ways todo the same thing is always going to be a maint burden, and in QEMU it has been especially burdensome as they were parallel impls in many cases, rather than one being exclusively built on top of the other. Even today we still get contributors sending patches which only impl HMP code and not QMP code. Separating HMP fully from QMP so that it was mandatory to create QMP first gets contributors going down the right path, and should reduce the burden on maint. At some point we are likely to introduce a new non-backwards compatible QEMU binary. Perhaps when Philippe completes his "all targets/machines in one binary" work. That would be an opportunity to carve HMP off into a separate out of process facade talking over QMP. That's only possible though if we get existing HMP into being a layer over QMP with no backdoor parallel impls. So anything we can do today to better separate QMP/HMP will give us more flexibility when the time arrives to create a new QEMU binary without backwards compat cruft. NB, introducing a new binary does not imply that the old binaries go away. They would probably stick around for legacy compat for a good while. For anything using libvirt though, we would be able to switch to the new binaries pretty fast without, as libvirt can translate app XML config to either the new or old QEMU dynamically. > Does the new program becomes basically an external project unrelated to > QEMU, that simply talks to QMP like libvirt does? It could be a separate project under QEMU on github, or it could just be binary in qemu.git. What matters is that it is out of the main QEMU process eventually. > I wonder how close to tools like qmp-shell, qmp-tui, etc that would > become and whether we might actually be looking at a substitute of > qemu.qmp. qmp-shell is rather too crude in terms of its data input/output - have to switch to JSON way too much, and there's no mechanism for formatting complex QMP replies into pretty human friendly data. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
