Re: Modern HMP

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Feb 04, 2026 at 09:08:49AM +0100, Markus Armbruster wrote:
>> "Dr. David Alan Gilbert" <dave@treblig.org> writes:
>> 
>> > * Daniel P. Berrangé (berrange@redhat.com) 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 ?

Yes.  It's how HMP works today.