From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a17:907:686:b0:a6f:1bf6:7fc1 with SMTP id wn6csp466745ejb; Sun, 9 Jun 2024 22:20:44 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVM/5Bg8nff+pVhlP5aqO6PC7GeBHgpLmrS+ABvV74LV0yEEc0ypI8gNqiCQ6+kbGrG7o9/HCZ42eWLyxBuguQM/cldl5UF X-Google-Smtp-Source: AGHT+IEQ/+Jl8TLX/JwgxHjNBr/NzZA32UKBGEKDolUJkBuB/xDnNrepTnmYfp5CbODFnP1ebifH X-Received: by 2002:a05:622a:5cb:b0:441:78:4ddd with SMTP id d75a77b69052e-44100785550mr14887821cf.32.1717996844007; Sun, 09 Jun 2024 22:20:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1717996843; cv=none; d=google.com; s=arc-20160816; b=k9VAF6kG1Q4s/tdiFbHfgV1X/39zbmvt+By7KZxrnYfstr1gz0GPZEE5ppHhKlkFSz eUB+QYDjVVNqRZcKVjLxfSFLKr3C2INPGVjtjlPX5zv3SNFAH83PB54IEkYZ/LeMizhT Yl7cmoZj/BxYosRKfyXK7GDZKUdrxncyZEmV7IIgCJtdLjQYMOnMditikZwMyVY2jgUG O2fQN22WxSd7m1J+To3khKLyRk/hQt/M5QWRuBPPhIh9F/RM4jRqSwhyrIwC61+t+7vi IQUnbYDtgm2MoS3bu8Rb8gmJCkAQfngPMRZi4HufubCz6gXxFHprUmNMigsKoaVLj46i 6Vqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:dkim-signature; bh=svY5H/Wx7L7PtA87wn20j9OYTIRwws86F115fnHjXIc=; fh=2AYjfKq1T17y1T6jtZ3kUBDHGko1BBAGnWn8dEe+vww=; b=qRoc3Z7fPBlYk+B93gi8mBy5KNlrkzCSWcUn/BgAN4r5yX0rW8aQXPOo2558jhdHqs jhg0Z0Bwsut/GTSc4JZz1na1FBBuMI6Plw4acl5V0EJNx7l0en9w9yG2WC/b/X2jXAf5 z1BwWNjRbQE3LoBOXRcVZdGtSyOX5DQKJhmA5sngTkznX0ULWNyLOE1dRssG4iY1DBU5 9txPaiARbItb/jWsGEOm02F2DCJPvv2Utopv1pmpAqqABbb31biXbsR2CAt75/EoZFtL P0rnYVPdns/8HfJdZTD5sZMGAYqyHn8sV5eRJsr48gM297BLCpNvImNS3sW88p5/J1Bx iV7g==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Qw5b9QzK; spf=pass (google.com: domain of armbru@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=armbru@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com. [170.10.129.124]) by mx.google.com with ESMTPS id d75a77b69052e-44038b17a17si96276271cf.286.2024.06.09.22.20.43 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Jun 2024 22:20:43 -0700 (PDT) Received-SPF: pass (google.com: domain of armbru@redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Qw5b9QzK; spf=pass (google.com: domain of armbru@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=armbru@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717996843; 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=svY5H/Wx7L7PtA87wn20j9OYTIRwws86F115fnHjXIc=; b=Qw5b9QzKY+EksTO2NoeNIFD9i0Yt//op4jx6EHjjbvs1LgnT9W/doZSC9oFYkPqqF7iW1K 3WvdJQzGKu1f/wRtyrMpR9pga8oLPUKdUejNdwU8EYU1AZKRmlW/ANYPsW55vPtmNfBugr jC0mnT/ERJJd0TE6jUAXKnoGz4YLCjo= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-471-SY6Q_EMLO_2J9AMMOsjcLg-1; Mon, 10 Jun 2024 01:20:39 -0400 X-MC-Unique: SY6Q_EMLO_2J9AMMOsjcLg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9C60129AA381; Mon, 10 Jun 2024 05:20:38 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.39.192.93]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CF754C158D0; Mon, 10 Jun 2024 05:20:37 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id AB83821E6757; Mon, 10 Jun 2024 07:20:36 +0200 (CEST) From: Markus Armbruster To: "Dr. David Alan Gilbert" Cc: Markus Armbruster , Philippe =?utf-8?Q?Mathieu-Dau?= =?utf-8?Q?d=C3=A9?= , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Thomas Huth , qemu-devel@nongnu.org, Cornelia Huck , David Hildenbrand , Alex =?utf-8?Q?Benn=C3=A9e?= , 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 In-Reply-To: (David Alan Gilbert's message of "Wed, 5 Jun 2024 11:44:07 +0000") References: <20240530074544.25444-1-philmd@linaro.org> <87y17lcni7.fsf@pond.sub.org> <875xup81u9.fsf@pond.sub.org> Date: Mon, 10 Jun 2024 07:20:36 +0200 Message-ID: <87zfrts7a3.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) 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.11.54.8 X-TUID: ntF9DnFQ7cSb "Dr. David Alan Gilbert" writes: > * Markus Armbruster (armbru@redhat.com) wrote: >> Philippe Mathieu-Daud=C3=A9 writes: >>=20 >> > Hi Daniel, Dave, Markus & Thomas. >> > >> > On 4/6/24 06:58, Markus Armbruster wrote: >> >> "Dr. David Alan Gilbert" writes: >> >>> * Daniel P. Berrang=C3=A9 (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=C3=A9 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=C3=A9 (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 t= hink >> >>>>> 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 targe= ts >> > return something (even if it is an empty list), confusing management >> > interface. >>=20 >> Loss of introspection precision is a concern, not a hard "no". >>=20 >> We weigh all the concerns, and pick a solution we hate the least :) >>=20 >> > 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, wh= ich >> >> may be useful when the command becomes available in qemu-systems capa= ble >> >> 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". >>=20 >> In practice, it's closer to "HMP must be base on QMP when the >> functionality does or should exist in QMP." >>=20 >> > Now we realize HMP >> > became stable because QMP-exposed, although not consumed externally... >>=20 >> I'm afraid I didn't get this part. >>=20 >> > 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 poi= nt >> > of exposing to QMP commands that will never be accessed there? >> > >> >>>> That was going to be my question too. Seems like its possible to si= mply >> >>>> stub out the existing command for other targets. >> >> >> >> That's going to happen whether we rename the commands or not. >> >>=20 >> >>> Are these commands really supposed to be stable, or are they just de= bug >> >>> commands? If they are debug, then add the x- and don't worry too mu= ch. >> > >> > 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"'. >>=20 >> 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 sh= ake > 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 t= he > 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. When you add special feature 'unstable', the tooling insists you cover it in the doc comment. Review should then ensure the doc comment explains why it is unstable. Examples: # @unstable: Member @x-perf is experimental. # @unstable: This command is meant for debugging. > 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". >>=20 >> 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. >>=20 >> [...] >>=20