From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a17:906:bc9a:b0:a66:557b:2f6e with SMTP id lv26csp188113ejb; Wed, 5 Jun 2024 04:44:10 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUXr/I00NaqgIzXnMDnjHF2XyXK3J+T/M4QUGo+CRMbBKi68D5vk0cO80/sgGQQga7DQgmC+be0BAdFMrTtJbLhPP8sfxiJ X-Google-Smtp-Source: AGHT+IFj8o8bPSRhNv6HfiPACvKxJOZpFw/HoCnqNDeCdB+aUZ3qEdKS/j8RhN69aKEJMFcImJGy X-Received: by 2002:a05:651c:446:b0:2e5:3f56:2a0e with SMTP id 38308e7fff4ca-2eac7a0d1b2mr13550361fa.24.1717587850409; Wed, 05 Jun 2024 04:44:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1717587850; cv=none; d=google.com; s=arc-20160816; b=A6xGyuw3Vrv44x3jKSAStCIutDaz7XeMLrTuIEdGf75xhgv8RVuQ0+yRFDRKuM3y83 aZ1tQZ+Zhfh5AqkafvzxR6qDfeWwmkxLFa5XJE/PozSLYpAub9BtkPI4vJr5gQy2Eftm NFfhr0LIuh1o5iBrZldmSmZLAXjqlo74ycDnv/+EDf59GbSuwGRYCExSwgMdV+S91MaE 2xv8LQES4+3RCpMFPYMOMSCy1zf9Wi23UCrFzce97CAywyyV8uAgvdf43P1bweNPtXNk 0pzaksMf9Inohsxm1CR9etyHIRiTeYTfD90ISopoVSQERK8bEwLxqXCvKPnYtQHBOoGj s2Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=oJ0SSFauIGrHm+2hvBfLoe69KArfehtAv7kHKWRi4JA=; fh=PQLPyn1C4Gc1ndsw5Dwmh4k2pvwcsm2hWG5AArFPXMk=; b=MwekzWLGS+Ro12tnsk4E0QOmXPSFrVy6YwIX5vPD9sGfyg3Lc8qLvHnH2SqnYF8jmq EDtCR9DLz7IHr74KI1dTNRlJ1HURfK0Js4snWbxziZjbsmZ8MrbbrYUmDXAdyfwKMyFO j7vIWn0bNqt2mSwrVOSho+NyH2uNMyxaw9O0XcjSOKEkKYYAjO3ClFuG3pwGs69X9H+s rUk37HQ5FPpofDZnjqrSmV3INpALHu/Ag6JDcdg7GnTHNlxo3gsaOcjWmlXS4fQKPxoN 3JVVA+/lLJSG3Drq6UcyIvYmzBobQGgyz3hHjfgzaSzItl0xuZI6QKGhiDa/g745HD4i Cxdw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@treblig.org header.s=bytemarkmx header.b=Q6xWif4W; spf=pass (google.com: domain of dg@treblig.org designates 2a00:1098:5b::1 as permitted sender) smtp.mailfrom=dg@treblig.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=treblig.org Return-Path: Received: from mx.treblig.org (mx.treblig.org. [2a00:1098:5b::1]) by mx.google.com with ESMTPS id ffacd0b85a97d-35e4f9f706csi5375772f8f.467.2024.06.05.04.44.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jun 2024 04:44:10 -0700 (PDT) Received-SPF: pass (google.com: domain of dg@treblig.org designates 2a00:1098:5b::1 as permitted sender) client-ip=2a00:1098:5b::1; Authentication-Results: mx.google.com; dkim=pass header.i=@treblig.org header.s=bytemarkmx header.b=Q6xWif4W; spf=pass (google.com: domain of dg@treblig.org designates 2a00:1098:5b::1 as permitted sender) smtp.mailfrom=dg@treblig.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=treblig.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=treblig.org ; s=bytemarkmx; h=Content-Type:MIME-Version:Message-ID:Subject:From:Date:From :Subject; bh=oJ0SSFauIGrHm+2hvBfLoe69KArfehtAv7kHKWRi4JA=; b=Q6xWif4WxErxBP4n ncPmqfO6TAH7cYvSx2OMzSCJZuucdSY29gtl0WDPEAFbt1U7pORK0xiezyNnM1io7qWohmdGnKPOY cL3/t9Pa1dmumUnw+J4yMdQha706UolYXkmYPJ1ZsrmJRGBe19O82Q+3IkOYgNZBvwnGcJPAGHUnz 1uPBtQm8V6xGkapI0n9Byb0HBYgvyHaHnS56e2q2sutpL7n3tNC0UiSNopS8a7j6OqyIpq0dRlnAP 14PUr7uJ2S+m7apMdS8jLApbK8Si9zOXSCNJQxlhg1mDDNtjR0vlhIOG3GujeVRNuXVNukAZjTio1 YEQ6FdYupZ1KjTP5NQ==; Received: from dg by mx.treblig.org with local (Exim 4.96) (envelope-from ) id 1sEp3o-004PF3-08; Wed, 05 Jun 2024 11:44:08 +0000 Date: Wed, 5 Jun 2024 11:44:07 +0000 From: "Dr. David Alan Gilbert" To: Markus Armbruster Cc: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Thomas Huth , qemu-devel@nongnu.org, Cornelia Huck , David Hildenbrand , Alex =?iso-8859-1?Q?Benn=E9e?= , Christian Borntraeger , qemu-s390x@nongnu.org, devel@lists.libvirt.org, Eric Farman , Ilya Leoshkevich , Richard Henderson , Eric Blake , Halil Pasic , Anton Johansson , qemu-arm Subject: Re: [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate Message-ID: References: <20240530074544.25444-1-philmd@linaro.org> <87y17lcni7.fsf@pond.sub.org> <875xup81u9.fsf@pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <875xup81u9.fsf@pond.sub.org> X-Chocolate: 70 percent or better cocoa solids preferably X-Operating-System: Linux/6.1.0-21-amd64 (x86_64) X-Uptime: 11:37:42 up 27 days, 22:51, 1 user, load average: 0.00, 0.00, 0.00 User-Agent: Mutt/2.2.12 (2023-09-09) X-TUID: cZL3F2jALfO9 * Markus Armbruster (armbru@redhat.com) wrote: > Philippe Mathieu-Daudé writes: > > > Hi Daniel, Dave, Markus & Thomas. > > > > On 4/6/24 06:58, Markus Armbruster wrote: > >> "Dr. David Alan Gilbert" writes: > >>> * Daniel P. Berrangé (berrange@redhat.com) wrote: > >>>> On Fri, May 31, 2024 at 06:47:45AM +0200, Thomas Huth wrote: > >>>>> On 30/05/2024 09.45, Philippe Mathieu-Daudé wrote: > >>>>>> We are trying to unify all qemu-system-FOO to a single binary. > >>>>>> In order to do that we need to remove QAPI target specific code. > >>>>>> > >>>>>> @dump-skeys is only available on qemu-system-s390x. This series > >>>>>> rename it as @dump-s390-skey, making it available on other > >>>>>> binaries. We take care of backward compatibility via deprecation. > >>>>>> > >>>>>> Philippe Mathieu-Daudé (4): > >>>>>> hw/s390x: Introduce the @dump-s390-skeys QMP command > >>>>>> hw/s390x: Introduce the 'dump_s390_skeys' HMP command > >>>>>> hw/s390x: Deprecate the HMP 'dump_skeys' command > >>>>>> hw/s390x: Deprecate the QMP @dump-skeys command > >>>>> > >>>>> Why do we have to rename the command? Just for the sake of it? I think > >>>>> renaming HMP commands is maybe ok, but breaking the API in QMP is something > >>>>> you should consider twice. > > > > I'm looking at how to include this command in the new "single binary". > > > > Markus explained in an earlier series, just expanding this command as > > stub to targets that don't implement it is not backward compatible and > > breaks QMP introspection. Currently on s390x we get a result, on other > > targets the command doesn't exist. If we add a stubs, then other targets > > return something (even if it is an empty list), confusing management > > interface. > > Loss of introspection precision is a concern, not a hard "no". > > We weigh all the concerns, and pick a solution we hate the least :) > > > So this approach use to deprecate process to include a new command > > which behaves differently on non-s390x targets. > > > > If we don't care for this particular case, better. However I'd still > > like to discuss this approach for other target-specific commands. > > > >> PRO rename: the command's tie to S390 is them immediately obvious, which > >> may be useful when the command becomes available in qemu-systems capable > >> of running other targets. > >> > >> CON rename: users need to adapt. > >> > >> What are the users? Not libvirt, as far as I can tell. > > > > Years ago we said, "all HMP must be based on QMP". > > In practice, it's closer to "HMP must be base on QMP when the > functionality does or should exist in QMP." > > > Now we realize HMP > > became stable because QMP-exposed, although not consumed externally... > > I'm afraid I didn't get this part. > > > Does the concept of "internal QMP commands" makes sense for HMP debug > > ones? (Looking at a way to not expose them). We could use the "x-" > > prefix to not care about stable / backward compat, but what is the point > > of exposing to QMP commands that will never be accessed there? > > > >>>> That was going to be my question too. Seems like its possible to simply > >>>> stub out the existing command for other targets. > >> > >> That's going to happen whether we rename the commands or not. > >> > >>> Are these commands really supposed to be stable, or are they just debug > >>> commands? If they are debug, then add the x- and don't worry too much. > > > > OK. > > > >> docs/devel/qapi-code-gen.rst: > >> > >> Names beginning with ``x-`` used to signify "experimental". This > >> convention has been replaced by special feature "unstable". > >> > >> Feature "unstable" is what makes something unstable, and is what > >> machines should check. > > > > What I mentioned earlier could be 'Feature "internal" or "debug"'. > > What's the difference to "unstable"? It should be clear *why* something is marked x- - something that's marked 'x-' because the feature is still in development is expected to shake out at some point, and the interface designed so it can. (and at some point the developer should get a prod to be asked whethere the x- can be removed). That's different from it permenantly being x- because it's expected to change as the needs of the people debugging change. Dave > >> An "x-" prefix may still be useful for humans. Machines should *not* > >> key on the prefix. It's unreliable anyway: InputBarrierProperties > >> member @x-origin is stable despite it's name. Renames to gain or lose > >> the prefix may or may not be worth the bother. > > > > Could follow the rules and be renamed as "origin-coordinate-x". > > I don't think it's worth the trouble. The "x-" prefix is now strictly > for humans, and humans can figure out what the x- in @x-origin, > @y-origin means. > > [...] > -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/