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 X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1EA0CC433E0 for ; Tue, 16 Feb 2021 13:55:07 +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 454F564DEC for ; Tue, 16 Feb 2021 13:55:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 454F564DEC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:55346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lC0oj-0000Fv-6W for qemu-devel@archiver.kernel.org; Tue, 16 Feb 2021 08:55:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52732) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC0nf-0008En-Cy for qemu-devel@nongnu.org; Tue, 16 Feb 2021 08:53:59 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:34077) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lC0nc-0006cE-Tt for qemu-devel@nongnu.org; Tue, 16 Feb 2021 08:53:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613483634; 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=L9KqfUBifrsqfrMCTxIb1ceMmghnx6ZRrRY09V39FsU=; b=a98sGSGFrKjtihtCBAaYpww5VJaKC1pSs9/N/xqPl6hmn7e27bviKHy4o+q/tFi/r4YUzM 5+T/4g/61UQHxU33rwgJNgxd7SLwysWAhesFBbhp3ZpWO30Yspf+SRemICezgSTVyoalLT SyNpFCYya80BI1DUXk94AziDHa70vq8= 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-258-fUzeCb07OHGZXEeuSpqRog-1; Tue, 16 Feb 2021 08:53:49 -0500 X-MC-Unique: fUzeCb07OHGZXEeuSpqRog-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A3E5C801975; Tue, 16 Feb 2021 13:53:48 +0000 (UTC) Received: from redhat.com (ovpn-112-215.ams2.redhat.com [10.36.112.215]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 96C2D10016F7; Tue, 16 Feb 2021 13:53:47 +0000 (UTC) Date: Tue, 16 Feb 2021 13:53:44 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Peter Maydell Subject: Re: [PULL 31/31] qemu-option: warn for short-form boolean options Message-ID: References: <20210123143128.1167797-32-pbonzini@redhat.com> <378df6af-8383-8a51-4286-54739dba99e4@redhat.com> <1a8f0b62-0adf-9360-2365-e9881a6aef94@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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=63.128.21.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_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.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Paolo Bonzini , QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Feb 16, 2021 at 01:36:46PM +0000, Peter Maydell wrote: > On Tue, 16 Feb 2021 at 13:30, Paolo Bonzini wrote: > > On 16/02/21 12:58, Peter Maydell wrote: > > > On Tue, 16 Feb 2021 at 11:23, Paolo Bonzini wrote: > > >> I agree, and that's why I have no plans to move -chardev off QemuOpts; > > >> warning is a different step than excising and sometimes years pass from > > >> one to the other. However, that doesn't prevent introducing a warning > > >> so that users slowly move away from the problematic functionality. > > > > > > If we want to continue to support the functionality then complaining > > > about it doesn't serve much purpose IMHO. > > > > It depends. I don't want to support it forever for all options; > > -machine, -accel and -object are those for which I do intend to remove > > support for short-form options after the two release deprecation period. > > > > My first submission of this patch even special cased "-chardev" to hide > > the warning, but this was dropped in response to reviews. > > (https://patchew.org/QEMU/20201103151452.416784-1-pbonzini@redhat.com/20201103151452.416784-5-pbonzini@redhat.com/). > > I can add that back if you prefer, since it's very simple. > > I agree with Daniel that it would be better to be consistent about > whether we like these short options or not, but disagree that > the answer is to deprecate everywhere :-) > > Broadly, I think that being able to say 'foo' when foo is a > boolean option being set to true is obvious and nice-to-use > syntax, and I don't really want it to go away. 'nofoo' for > 'foo=false' is much less obvious and I'm happy if we only > support it as a special-case for 'nowait'. There's an inherant tension in our goals here. It is widely thought that QEMU configuration is complex and painful to understand. From my POV a big part of that believe comes from the fact that we have so many inconsistencies in our parsing code, and many ways of doing the same thing. Every time we have special cases like "foo" as a short hand for "foo=on" or "nofoo" as a short hand for "foo=off", we increase the complexity of QEMU and that impacts how our users view QEMU. IMHO we'd be better off eliminating the boolean short forms entirely in all QEMU options, so that we get consistency and a clearer right way of doing things. The short bool format was created with good intentions, but on balance a bare "foo" isn't a big enough win over "foo=on" to justify its existance long term. I do agree though, that we should not be deprecating something if our documentation is still showing people the deprecated syntax, as that makes us look even worse. 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 :|