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.129.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 7881E3D647A for ; Thu, 22 Jan 2026 16:00:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769097638; cv=none; b=pmN09+EC+mNJjGayf0dHgwRHGAi4h7bNMQT9ZZzOvysdXhu5S+nezb9mxFMjS/ox7CkqvWSe2HRQ6/Q6TQhVEonkyebw3RH9hTn9st5n9u5rCE32RBqghtUcUCkiYCQQFWSWiR6DuoTPt/w32APkqXCED7m2TbEUpBoZP282IEU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769097638; c=relaxed/simple; bh=XnKAwO0yUTasmFWNWowWhkvsk3AGb+0t6qJNdQnFUe4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Wx6IlbSMIpSmGeAruxf8IUGIPMnJNFZJhQx9LX3mu1wJrWM5P+J2hwxnn6QgXcTAoVWwCpdi2pG6FUOb0Bl1FJDGmELk+V6njW+2moxFwBgbYRpW2oo6f7qzMGo/O4UBWGxus8nYlSrEA4D6sQZ6XCHmISzqxavtEV6Zll1BlG4= 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=hD1TXWNG; arc=none smtp.client-ip=170.10.129.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="hD1TXWNG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769097630; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=jHh0MFWSMKz2Mm8GLTGEiKUH5WEgc8+dxDyDtFMoWFE=; b=hD1TXWNGkWXHw4v3i6iTRO+q5kgbmnAjZ47sg79jYk/dM621MjOxky3eZust4kApWdrOJX TwioGOiXdCfexOD8w29B+vikIgsLNjqr72gjphVH7eYjY6xeTO7GhR0/8kQTUgqI+qyFiw K4kmg1njsfFV4sBtQIJk2qOwy1COu3g= Received: from mx-prod-mc-08.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-231-CWeYt54yN8yqA20RDrVH-w-1; Thu, 22 Jan 2026 11:00:27 -0500 X-MC-Unique: CWeYt54yN8yqA20RDrVH-w-1 X-Mimecast-MFC-AGG-ID: CWeYt54yN8yqA20RDrVH-w_1769097626 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B39F118002CC; Thu, 22 Jan 2026 16:00:25 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.63]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B339918004D8; Thu, 22 Jan 2026 16:00:20 +0000 (UTC) Date: Thu, 22 Jan 2026 16:00:17 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Fabiano Rosas Cc: Markus Armbruster , =?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 Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <871pjigf6z.fsf_-_@pond.sub.org> <87ikctg8a8.fsf@pond.sub.org> <87ikctk5ss.fsf@suse.de> 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-Disposition: inline In-Reply-To: <87ikctk5ss.fsf@suse.de> User-Agent: Mutt/2.2.14 (2025-02-20) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 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 :|