From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75A3220DD75 for ; Wed, 4 Feb 2026 08:08:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770192540; cv=none; b=vALPUzB4+EYkJt3A4qgna1u4lGYqTGaowVx+yFVBFCe5/AscOEfp7/Ya4XSxmvKGiXOOPPG3jGtYRaUjL/oH2bi2dZu/hF94c/XoP0pxUOWrahdY9TYEx69HiS8fMHK8fEGX6RloWsifbTfOlsWfWNgMcEAor3yP4kNN7GotmBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770192540; c=relaxed/simple; bh=B9SwCh9y2gTvjS1kb5IFPfiPhNIzMcHz7dNu13hU/ls=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=EXLAswOTd33Qa2rg/c4fbyOl+uZ08JZI615P9zGr2hcwANTVWS6bfLzJJ7bkm5XdbXylLYKU+eHZ4tpmkW3xTW8pEfE3Td9kHNhdBfpi9yZCt6yF8QhyNEgI2rJAdoSStDvCiVG9kyKBfD0BehqsCoYvIQqEwEBIljgidrYhdsc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ZPdmeITQ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZPdmeITQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770192539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GQYc7vzJ+vLiqRcVbL9Fy4WFqd+/9YmBpyNDssdXXt0=; b=ZPdmeITQVzBiukMMyRHOhh96Jvb8RP6hPoo4Tr8JDfhSEyPlfM/1ERjyptRuVUAB3C2ACN VXyr5VypU+KDN3J0/WowxBA7f62RmMmZ6O17Ez9b3YgB/QcYI2XqHpGyDzmMCbjuOu0ssY EchtiNFYLId16d4yQf0UA2rjrsuQsmY= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-516-PC0MjxkQOJK99x-KRUBCzg-1; Wed, 04 Feb 2026 03:08:55 -0500 X-MC-Unique: PC0MjxkQOJK99x-KRUBCzg-1 X-Mimecast-MFC-AGG-ID: PC0MjxkQOJK99x-KRUBCzg_1770192534 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8E88F1800349; Wed, 4 Feb 2026 08:08:53 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.45.242.22]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3BD2730001A5; Wed, 4 Feb 2026 08:08:52 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id DE3BE21E692D; Wed, 04 Feb 2026 09:08:49 +0100 (CET) From: Markus Armbruster To: "Dr. David Alan Gilbert" Cc: Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Fabiano Rosas , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Stefan Hajnoczi , qemu-devel , kvm , Helge Deller , Oliver Steffen , Stefano Garzarella , Matias Ezequiel Vara Larsen , Kevin Wolf , German Maglione , Hanna Reitz , Paolo Bonzini , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Thomas Huth , Mark Cave-Ayland , Alex Bennee , Pierrick Bouvier Subject: Re: Modern HMP In-Reply-To: (David Alan Gilbert's message of "Sun, 1 Feb 2026 18:29:53 +0000") References: <871pjigf6z.fsf_-_@pond.sub.org> <87ikctg8a8.fsf@pond.sub.org> <87ikctk5ss.fsf@suse.de> Date: Wed, 04 Feb 2026 09:08:49 +0100 Message-ID: <875x8d0w32.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 "Dr. David Alan Gilbert" writes: > * Daniel P. Berrang=C3=A9 (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? >>=20 >> 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 exclusi= vely >> built on top of the other. >>=20 >> 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 int= erface > 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. So we retreated from "all", and permitted exceptions for commands that make no sense in QMP. We then found out the hard & expensive way that designing a QMP command with its stable, structured interface is often a lot harder than cobbling together an HMP command. It's not just avoidable social problems ("bikeshedding"); designing stable interfaces is just hard. Sometimes the extra effort is worthwhile. Sometimes it's not, e.g. when all we really want is print something to aid a human with debugging. So we retreated from "all" some more, and permitted exceptions for commands meant exclusively for human use, typically debugging and development aids. This effectifely redefined the meaning of "complete": instead of "QMP can do everything HMP can do and more", it's now "... except for certain development and debugging aids and maybe other stuff". To keep "maybe other stuff" under control, we required (and still require) an *argument* for adding functionality just to HMP. This turned out to be differently bothersome. Having to review HMP changes for QMP bypasses is bothersome, and bound to miss things at least occasionally. Having to ask for an argument is bothersome. Constructing one is bothersome. To reduce the bother, we retreated from another QMP ideal: the structured interface. Permit QMP commands to return just text when the command is meant just for humans. Such commands must be unstable. Possible because we had retreated from "all of QMP is stable" meanwhile. How does this work? Instead of adding an HMP-only command, add a QMP command that returns QAPI type HumanReadableText, and a trivial HMP command that wraps around it. Slightly more work, but no interface design. The QMP command addition is much more visible to the QAPI/QMP maintainers than an HMP-only command would be. This helps avoid missing things. We still want an argument why a structured interface isn't needed. But we can be much more lenient there: if it turns out to be needed, we can just add it, and drop the unstructured interface. Remember, it's unstable. Hope this helps.