On Wed, Feb 04, 2026 at 09:08:49AM +0100, Markus Armbruster wrote: > "Dr. David Alan Gilbert" <[email protected]> writes: > > > * Daniel P. Berrangé ([email protected]) wrote: > >> 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. > > > > Having a separate HMP isn't a bad idea - but it does need some idea of > > how to make it easy for contributors to add stuff that's just for debug > > or for the dev. For HMP the bar is very low; if it's useful to the > > dev, why not (unless it's copying something that's already in the QMP > > interface > > in a different way); but although the x- stuff in theory lets > > you add something via QMP, in practice it's quite hard to get it through > > review without a lot of QMP design bikeshedding. > > I think this description has become less accurate than it used to be :) > > A long time ago, we started with "QMP is a stable, structured interface > for machines, HMP is a plain text interface for humans, and layered on > top of QMP." Layered on top means HMP commands wrap around QMP > commands. Ensures that QMP is obviously complete. Without such a > layering, we'd have to verify completeness by inspection. Impractical > given the size and complexity of the interfaces involved. > > Trouble is there are things in HMP that make no sense in QMP. For > instance, HMP command 'cpu' sets the monitor's default CPU, which > certain HMP commands use. To wrap 'cpu' around a QMP command, we'd have > to drag the concept "default CPU" into QMP where it's not wanted.
Surely the isolated HMP monitor code can just keep track of its view of a "default" CPU, and then pass an explicit CPU to the QMP commands it runs ? 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 :|
