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 52ACEC02194 for ; Fri, 7 Feb 2025 12:32:56 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tgNWh-0002dy-Vk; Fri, 07 Feb 2025 07:32:08 -0500 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 1tgNWf-0002dh-CT for qemu-devel@nongnu.org; Fri, 07 Feb 2025 07:32:05 -0500 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 1tgNWa-0000Fg-Ck for qemu-devel@nongnu.org; Fri, 07 Feb 2025 07:32:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738931517; 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: in-reply-to:in-reply-to:references:references; bh=+HJnaaX0XUKv/tnLrq1xTdWIg+Plz7a8uGyllk/CVmI=; b=cMuGH14qt7WrXRstdh0gr3aTNY/3SS6TpKWzuEkLafSbn2kQcmTdH+lpN6hxSQkX7d9tZW EASAM+NsI8gVSFM0ENuoMAeAYP50VmbFNzE0XOgNG0MQ0sNUABzke+mtDbMXzpadWNQMZO 7hynRk+Ty5KK36nV8nSDT14ZvdiC2ps= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-679-KiNcHzvmO1S32sF1W-rLrA-1; Fri, 07 Feb 2025 07:31:54 -0500 X-MC-Unique: KiNcHzvmO1S32sF1W-rLrA-1 X-Mimecast-MFC-AGG-ID: KiNcHzvmO1S32sF1W-rLrA Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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 mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 84E04195608C; Fri, 7 Feb 2025 12:31:52 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.45.242.26]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F32841956051; Fri, 7 Feb 2025 12:31:49 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 6C25E21E6A28; Fri, 07 Feb 2025 13:31:47 +0100 (CET) From: Markus Armbruster To: Akihiko Odaki Cc: BALATON Zoltan , Jason Wang , Dmitry Fleytman , Sriram Yagnaraman , "Michael S. Tsirkin" , Luigi Rizzo , Giuseppe Lettieri , Vincenzo Maffione , Andrew Melnychenko , Yuri Benditovich , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Eduardo Habkost , Michael Roth , Marcel Apfelbaum , Philippe =?utf-8?Q?Mathieu-Daud?= =?utf-8?Q?=C3=A9?= , Yanan Wang , Zhao Liu , Lei Yang , qemu-devel@nongnu.org Subject: Re: [PATCH v4 2/4] qdev-properties: Accept bool for OnOffAuto In-Reply-To: <79fea08e-21d0-46ba-923d-8892eef3ce8e@daynix.com> (Akihiko Odaki's message of "Fri, 7 Feb 2025 14:59:34 +0900") References: <20250108-virtio-v4-0-cbf0aa04c9f9@daynix.com> <20250108-virtio-v4-2-cbf0aa04c9f9@daynix.com> <87cyfwxveo.fsf@pond.sub.org> <44b21e4c-b076-41bb-9564-1e7a8cf4a450@daynix.com> <87r04bs8sj.fsf@pond.sub.org> <6e6935dd-fae7-4cce-acad-69609eba9b6e@daynix.com> <4363863f-3ba3-95b3-61ec-6fade162218f@eik.bme.hu> <79fea08e-21d0-46ba-923d-8892eef3ce8e@daynix.com> Date: Fri, 07 Feb 2025 13:31:47 +0100 Message-ID: <878qqihr64.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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 Akihiko Odaki writes: [...] > Let me go back to the discussion of the bool/OnOffAuto problem below: > > The values the command line syntax accepts are on/yes/true/y and off/no/false/n. > > For the command line syntax, you can always use on/off whether the type is bool or OnOffAuto. In my opinion, it is still not good to reject yes/true/y and no/false/n for OnOffAuto; why do we suddenly reject them when the property gets the "auto" value? As you pointed out, the usage of enum is our internal concern and should not bother users. The command line is a different mess. For better or worse (worse if you ask me), we added code to accept additional syntax for bool values. Doing the same for enums that happen to have some values that look boolean at a glance is in my opinion a terrible idea. We have at least two: OnOffAuto and OnOffSplit. But let's get back to QMP. > The situation is worse for JSON as there is no common literals that are compatible with both of bool and OnOffAuto, which forces users to remember the type. JSON is primarily for machines, and machines are very good at remembering the type. An argument can be made that OnOffAuto is problematic interface design. In fact, I made it; see "managed to maneuver ourselves into a bit of a corner" upthread. > So I think this patch makes sense in terms of usability. Accepting multiple representations for one value is ugly, but it is better than exposing the ugliness to users. We should deprecate the representations except one if we really hate the ugliness. I believe churn & complexity outweigh the benefits.