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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BCB0C433EF for ; Tue, 26 Oct 2021 15:02:57 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id BD73D604AC for ; Tue, 26 Oct 2021 15:02:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BD73D604AC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:56736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfNyZ-0006XI-Sj for qemu-devel@archiver.kernel.org; Tue, 26 Oct 2021 11:02:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfNt1-00079J-Sl for qemu-devel@nongnu.org; Tue, 26 Oct 2021 10:57:12 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:40538) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfNt0-0001Rf-0H for qemu-devel@nongnu.org; Tue, 26 Oct 2021 10:57:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635260227; 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=+t75zai9rxdPIpwKm9TymWF0bxxQQoekYL2ZBS7kr70=; b=RbKxdU69e1ej2ymxLGpbEybjuykDl3xUPPxQtAuuLKeB5RD3OmyybtQ+sr8d8S5QTJxj+7 ZXpacaRSUjLnQ+i9wliGAEvh14pp/kU7rd/nbjdea+BeyMwS4fIkh6qbzcWOV786wwes9F MslKOdOkkyO0veQhmKbMePk0kK6UW1Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-538-BerieSx3PTSNmvaq4PFp9A-1; Tue, 26 Oct 2021 10:57:04 -0400 X-MC-Unique: BerieSx3PTSNmvaq4PFp9A-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3E94519057A1; Tue, 26 Oct 2021 14:57:03 +0000 (UTC) Received: from redhat.com (unknown [10.39.194.218]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 75525AFD90; Tue, 26 Oct 2021 14:56:28 +0000 (UTC) Date: Tue, 26 Oct 2021 15:56:26 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Markus Armbruster Subject: Re: [PATCH 1/9] qapi: New special feature flag "unstable" Message-ID: References: <20211025052532.3859634-1-armbru@redhat.com> <20211025052532.3859634-2-armbru@redhat.com> <87r1c83z5c.fsf@dusky.pond.sub.org> MIME-Version: 1.0 In-Reply-To: <87r1c83z5c.fsf@dusky.pond.sub.org> User-Agent: Mutt/2.0.7 (2021-05-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Kevin Wolf , pkrempa@redhat.com, ehabkost@redhat.com, qemu-block@nongnu.org, quintela@redhat.com, libvir-list@redhat.com, eblake@redhat.com, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, dgilbert@redhat.com, pbonzini@redhat.com, marcandre.lureau@redhat.com, jsnow@redhat.com, libguestfs@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Oct 26, 2021 at 11:37:19AM +0200, Markus Armbruster wrote: > Kevin Wolf writes: > > > Am 25.10.2021 um 07:25 hat Markus Armbruster geschrieben: > >> By convention, names starting with "x-" are experimental. The parts > >> of external interfaces so named may be withdrawn or changed > >> incompatibly in future releases. > >> > >> Drawback: promoting something from experimental to stable involves a > >> name change. Client code needs to be updated. > >> > >> Moreover, the convention is not universally observed: > >> > >> * QOM type "input-barrier" has properties "x-origin", "y-origin". > >> Looks accidental, but it's ABI since 4.2. > >> > >> * QOM types "memory-backend-file", "memory-backend-memfd", > >> "memory-backend-ram", and "memory-backend-epc" have a property > >> "x-use-canonical-path-for-ramblock-id" that is documented to be > >> stable despite its name. > >> > >> We could document these exceptions, but documentation helps only > >> humans. We want to recognize "unstable" in code, like "deprecated". > >> > >> Replace the convention by a new special feature flag "unstable". It > >> will be recognized by the QAPI generator, like the existing feature > >> flag "deprecated", and unlike regular feature flags. > >> > >> This commit updates documentation and prepares tests. The next commit > >> updates the QAPI schema. The remaining patches update the QAPI > >> generator and wire up -compat policy checking. > >> > >> Signed-off-by: Markus Armbruster > > > > Obviously, replacing the old convention gets rid of the old drawbacks, > > but adds a new one: While using x- makes it very obvious for a human > > user that this is an unstable feature, a feature flag in the schema will > > almost certainly go unnoticed in manual use. > > I thought about this, but neglected to put it in writing. My bad. > > Manual use of unstable interfaces is mostly fine. Human users can adapt > to changing interfaces. HMP works that way. > > Management applications are better off with a feature flag than with a > naming convention we sometimes ignore. We will sometimes ignore/forget the feature flag too though, so I'm not convinced there's much difference there. > If we want to keep "unstable" obvious to the humans who write such > programs, we can continue to require "x-", in addition to the feature > flag. We pay for it with renames, and the risk of forgetting to rename > in time (which is what got us the awkward stable > "x-use-canonical-path-for-ramblock-id"). Tradeoff. I chose not to, but > if y'all think we should... IMHO the renames arguably make life easier for mgmt apps, as they only need to check for the name without the x- prefix, and they know they won't be accidentally using the fature from an older QEMU where it was unstable because the older QEMU had a different name they won't be checking for. We can just as easily forget to remove the "unstable" feature flag, as forget to rename. The plus point about the feature flag is that it is aligned with the "deprecated" feature flag, and potentially aligned with a future "insecure" feature flag. 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 :|