From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D92DBCDB465 for ; Thu, 19 Oct 2023 07:11:31 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtNAv-0002Dc-QD; Thu, 19 Oct 2023 03:10:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtNAt-0002D9-9L for qemu-devel@nongnu.org; Thu, 19 Oct 2023 03:10:31 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtNAq-00089I-NO for qemu-devel@nongnu.org; Thu, 19 Oct 2023 03:10:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697699427; 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=OXeXZEvAB6qsG5rHRYH4f8H6DPCd0ZklNqQbLCIHmJA=; b=SBnn5CVcn83Q7UCtUCQ/rI33W2qjXMpRQWhzGlOYWvSj/ElAMAhtA9TkoY09JyAOoZu35L mxz0usVz7nH8Y5T0Ug/xHfqN4UlNDT4fywAxRiuZFWv28HrYzqkdGmTKgCnVwgEVQEagAx g5vqUErScWuD6c2PoCNp2mkQ8X7Bn9I= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-153-FTpGfSCcPleASfsTYT5Pgw-1; Thu, 19 Oct 2023 03:10:23 -0400 X-MC-Unique: FTpGfSCcPleASfsTYT5Pgw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B3F75185A7B6; Thu, 19 Oct 2023 07:10:22 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.39.193.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 850BF40C6F7B; Thu, 19 Oct 2023 07:10:22 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 6922E21E6A1F; Thu, 19 Oct 2023 09:10:21 +0200 (CEST) From: Markus Armbruster To: Daniel P. =?utf-8?Q?Berrang=C3=A9?= Cc: "Michael S. Tsirkin" , Vladimir Sementsov-Ogievskiy , qemu-block@nongnu.org, qemu-devel@nongnu.org, eblake@redhat.com, dave@treblig.org, eduardo@habkost.net, pbonzini@redhat.com, hreitz@redhat.com, kwolf@redhat.com, raphael.norwitz@nutanix.com, yc-core@yandex-team.ru, den-plotnikov@yandex-team.ru, daniil.tatianin@yandex.ru Subject: Re: [PATCH 4/4] qapi: introduce CONFIG_READ event References: <20231006202045.1161543-1-vsementsov@yandex-team.ru> <20231006202045.1161543-5-vsementsov@yandex-team.ru> <87sf692t0i.fsf@pond.sub.org> <877cnkzasr.fsf@pond.sub.org> <878r80tdyd.fsf@pond.sub.org> <20231018064912-mutt-send-email-mst@kernel.org> <87o7gwp29r.fsf@pond.sub.org> Date: Thu, 19 Oct 2023 09:10:21 +0200 In-Reply-To: ("Daniel P. =?utf-8?Q?Berrang?= =?utf-8?Q?=C3=A9=22's?= message of "Wed, 18 Oct 2023 13:07:34 +0100") Message-ID: <87y1fzjdeq.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) 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.2 Received-SPF: pass client-ip=170.10.129.124; envelope-from=armbru@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Daniel P. Berrang=C3=A9 writes: > On Wed, Oct 18, 2023 at 02:02:08PM +0200, Markus Armbruster wrote: >> Daniel P. Berrang=C3=A9 writes: >>=20 >> > On Wed, Oct 18, 2023 at 06:51:41AM -0400, Michael S. Tsirkin wrote: >> >> On Wed, Oct 18, 2023 at 12:36:10PM +0200, Markus Armbruster wrote: >> >> > > x- seems safer for management tool that doesn't know about "unsta= ble" properties.. >> >> >=20 >> >> > Easy, traditional, and unreliable :) >> >>=20 >> >> > > But on the other hand, changing from x- to no-prefix is already >> >> > > done when the feature is stable, and thouse who use it already >> >> > > use the latest version of interface, so, removing the prefix is >> >> > > just extra work. >> >> >=20 >> >> > Exactly. >> >> >=20 >> >>=20 >> >> I think "x-" is still better for command line use of properties - we >> >> don't have an API to mark things unstable there, do we? >> > >> > Personally I like to see "x-" prefix present *everywhere* there is >> > an unstable feature, and consider the need to rename when declaring >> > it stable to be good thing as it sets an easily identifiable line >> > in the sand and is self-evident to outside observers. >> > >> > The self-documenting nature of the "x-" prefer is what makes it most >> > compelling to me. A patch submission, or command line invokation or >> > an example QMP command, or a bug report, that exhibit an 'x-' prefix >> > are an immediate red flag to anyone who sees them. >>=20 >> Except when it isn't, like in "x-origin". >>=20 >> > If someone sees a QMP comamnd / a typical giant QEMU command line, >> > they are never going to go look at the QAPI schema to check whether >> > any feature used had an 'unstable' marker. The 'unstable' marker >> > might as well not exist in most cases. >> > >> > IOW, having the 'unstable' flag in the QAPI schema is great for machine >> > introspection, but it isn't a substitute for having an 'x-' prefix used >> > for the benefit of humans IMHO. >>=20 >> I'm not sure there's disagreement. Quoting myself: >>=20 >> The "x-" can remind humans "this is unstable" better than a feature >> flag can (for machines, it's the other way round). >>=20 >> CLI and HMP are for humans. We continue to use "x-" there. >>=20 >> QMP is for machines. The feature flag is the sole source of truth. >> Additional use of "x-" is fine, but not required. > > I guess we have different defintions of "for humans" in this context. > I consider QMP data still relevant for humans, because humans are > reviewing patches to libvirt that add usage of QMP features, or There's a much more reliable way: 1. Require tests 2. Run them with -compat unstable-input=3Dreject,unstable-output=3Dhide Or unstable-input=3Dcrash if you don't trust or don't want to rely on your test harness. > triaging bug reports that include examples of usage, Here you can run the reproducer with -compat. > and in both > cases it is pretty relevant to make unstable features stand out to > the human via the x- prefix IMHO. Your point remains at least somewhat valid all the same.