From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a17:906:7fcb:b0:a66:557b:2f6e with SMTP id r11csp2701157ejs; Mon, 3 Jun 2024 21:58:55 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWX6G3x+7HV+lHQiIP8b/lMyvYdhv7vYZb8GvWY8ptG/VEcDpq+6FuUlRHe8vqvEBg7mLSvDKUWjhhWKfRC3ZPYnMXaa01H X-Google-Smtp-Source: AGHT+IEHzPtaXmzK/m6TsaKjxUJ92OyF/pmccU34MFoh8Gs98J3tkBgzjqAlgl6F3u+AtU+8savS X-Received: by 2002:a05:620a:bc8:b0:792:f046:b51d with SMTP id af79cd13be357-794f5c89f4cmr1503049185a.46.1717477134847; Mon, 03 Jun 2024 21:58:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1717477134; cv=none; d=google.com; s=arc-20160816; b=TitAngYx/LR2UrWSBa0roG23FuGiP1MlbykGBhLUpI0Go4g+lUWv6z3D9YhpDQtvMN IWqsOrOJ+qq0NFA/XW9okAv47cWIeO9U98m/5Gsm4bm5cAPPOijYoGfqu39DDi0gAltY QrJirsNnJe1Zk47QVL0Y2lc0CYBgPDptASqqtVAQushe+zQsB7PrQOtTZhX29k7vq/kh xTdRtMVwmzC9wSHuwyP1ol4cFXip5jmUNfX4yzpgbArcTvTllU1qOL2qkmAn/0hnxZiq UxbLmRDDHo1qnEaCraO2Qe88YswvF4x0jWbEx4Z9B2r5PAta3OUxEYBr1DK3lQ4v6+X3 Cj3g== 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=Bq+7Q0aVVfcomC4fBqffFBZ1gvdnJxDCNC5r+0OIDjs=; fh=m1/BsG0XtixjKFWnO27KIC/YCPTbibrETxjCIcDFGSM=; b=jC53DW6qXExc1/U+SogAa+2u4ri1oZFromLQ5DPzgU6XC4pRjzbrFyZOcaD6TmzWez 1ul4DGc6QKydKfkSzbWcR3hjXbjc9+58GQ7pimyAh8PYhWeJPTjPvwVzgUNpNFuCDI+2 ERwcX5UhKXw4ysQx7Yx4XZd40cyNjdLkX5Al2TlQuVw1lsCIJnJeJm1eEWoEcseW++Cw 1F+vp5kdPFQej+RFqGzygg1V0dvi+3UC8kpJiLw6NucI9bYV2VRd9aK2Y+WZkIuRgFFu hTvScsCGJhaIBdawCh9hTuQzfmPzPJHx4ng4xlOtXC6b4nK1kpHSYEP5ZyWl/KLkjbk5 D4cA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QeDJf1qU; spf=pass (google.com: domain of armbru@redhat.com designates 170.10.133.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.133.124]) by mx.google.com with ESMTPS id af79cd13be357-79510bda0f5si23412785a.370.2024.06.03.21.58.54 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jun 2024 21:58:54 -0700 (PDT) Received-SPF: pass (google.com: domain of armbru@redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.124; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QeDJf1qU; spf=pass (google.com: domain of armbru@redhat.com designates 170.10.133.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=1717477134; 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=Bq+7Q0aVVfcomC4fBqffFBZ1gvdnJxDCNC5r+0OIDjs=; b=QeDJf1qUc5L8Ob8zEIO+wubihfEAPLkZg3WgETZFH2Q4EG0omPdHwZsEVu7fyxds5pj71x OZPcW26Z7fWFMCiJfX6M5WiO8tUMqllnaWOlLpN1qcrtFPk+DFi84oAE3dU7xHVj4rZmUM TWl1RLr3asIdD+JjjjflR33OsxcHg6E= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-552-I6DWwb-cPxWL5Fo4JisOSw-1; Tue, 04 Jun 2024 00:58:42 -0400 X-MC-Unique: I6DWwb-cPxWL5Fo4JisOSw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (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 28F8D85A58C; Tue, 4 Jun 2024 04:58:42 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.39.192.93]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5BE3F28A2; Tue, 4 Jun 2024 04:58:41 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 5B15821E6757; Tue, 4 Jun 2024 06:58:40 +0200 (CEST) From: Markus Armbruster To: "Dr. David Alan Gilbert" Cc: Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Thomas Huth , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , 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 "Mon, 3 Jun 2024 20:54:24 +0000") References: <20240530074544.25444-1-philmd@linaro.org> Date: Tue, 04 Jun 2024 06:58:40 +0200 Message-ID: <87y17lcni7.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.5 X-TUID: EM9bGmWAHEMq "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. >> > >=20 >> > > @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. >> > >=20 >> > > 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 >> >=20 >> > 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 some= thing >> > you should consider twice. 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. >> 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. 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. 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. Making an existing part of the interface unstable should be treated similar to deprecating it: we keep it stable for at least the deprecation period. Not written policy, because we didn't consider such changes when we documented our deprecation policy in docs/about/deprecated.rst. Alternative path to a renamed command (*if* we want that): 1. Make it unstable. 2. But keep it stable for two releases. 3. Rename. [...]