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=-2.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 38821C433DB for ; Tue, 16 Feb 2021 14:47:43 +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 AF71E64DF5 for ; Tue, 16 Feb 2021 14:47:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AF71E64DF5 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]:60730 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lC1dd-0003Uj-GH for qemu-devel@archiver.kernel.org; Tue, 16 Feb 2021 09:47:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37662) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC1bv-0002gv-LB for qemu-devel@nongnu.org; Tue, 16 Feb 2021 09:45:55 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:52534) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lC1br-00042a-Ob for qemu-devel@nongnu.org; Tue, 16 Feb 2021 09:45:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613486749; 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=1PM0S1JVUEZmCOWspvhKaJWZ2PQT95X8HAj0WMFpJyo=; b=crsEGYzm/n0vDlgbWWjJgTfFS5zVSgfS1sZe8jzzVxK8Xb9xnI19xMKR4hOzX96MFmu/Na AYRoUVL0a4YgAPfU0LXySPqyyT5JS7oiMrMJ5Ag5bsO2cBsBOyAyq+KkO7ZbzJRx8/xOKg KSkgoubcrODy/ZGp3J+5GJjhJP+8G/8= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-584-1rjCsVAaN5ia7NEE0O1iqA-1; Tue, 16 Feb 2021 09:45:47 -0500 X-MC-Unique: 1rjCsVAaN5ia7NEE0O1iqA-1 Received: by mail-pl1-f197.google.com with SMTP id s5so9265062plg.14 for ; Tue, 16 Feb 2021 06:45:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1PM0S1JVUEZmCOWspvhKaJWZ2PQT95X8HAj0WMFpJyo=; b=AK4AbOOWGBkg0G2+2RJavropR+uwxYZADYABpEeVeCvg3mqwdUGwsczRQhvWafAILq hA/dEgYimdNLYCsyxPH0e11m9HT4qI3JnxeDUcg/6r8Vj7RMxMawv8mT85D75EWrqTfw nqqfR+vBsdOvJFkQp/0l1ECQ8N8QGt1Q2IjmzR4AXA5m2U9oIAuy4EdQREGYfmNky1EU J0QbX4m4dnZjW9HwxJyPHmKlqKeeN18osWgog6oFVY1/4HDp9yW81fy9+giu00+N4VVV Klv5mtMEHclrVFV1O1G0ghbUI5jXK67/tAxxqEmMEQLj1brOpSR0NAioRmsNMhTjffuj dXtg== X-Gm-Message-State: AOAM533fdT5FZwBIp+ls5tHJC3bixJpI9ZgXr2UtTo2rdWJM+0T9kMBu zlFfUz/MJU4Km+H4kaUA+6XKKOywjQqxsCksoZ9r324/phEbnJE7q7a4DSa2v1EqI/WrnbYR7u/ o2NQl6MdNAwkN0lCtO/m4vjb29osZdY0= X-Received: by 2002:a05:6a00:8f:b029:1e8:6975:395e with SMTP id c15-20020a056a00008fb02901e86975395emr20021336pfj.55.1613486746178; Tue, 16 Feb 2021 06:45:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJxS3BWw6cfmbUXcZ13n4kdC+MaqZkUdIQmF/szoO7lCvp8yrGilFVCuHrzietHY4ZzALoItekl6dP5b/4eQ45s= X-Received: by 2002:a05:6a00:8f:b029:1e8:6975:395e with SMTP id c15-20020a056a00008fb02901e86975395emr20021322pfj.55.1613486745874; Tue, 16 Feb 2021 06:45:45 -0800 (PST) MIME-Version: 1.0 References: <20210123143128.1167797-1-pbonzini@redhat.com> <20210123143128.1167797-32-pbonzini@redhat.com> <378df6af-8383-8a51-4286-54739dba99e4@redhat.com> <1a8f0b62-0adf-9360-2365-e9881a6aef94@redhat.com> <9f9999eb-66a5-3fe4-64fe-41f64edb49ff@redhat.com> In-Reply-To: From: Paolo Bonzini Date: Tue, 16 Feb 2021 15:45:33 +0100 Message-ID: Subject: Re: [PULL 31/31] qemu-option: warn for short-form boolean options To: Peter Maydell Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="00000000000056949005bb752804" Received-SPF: pass client-ip=63.128.21.124; envelope-from=pbonzini@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, HTML_MESSAGE=0.001, 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: , Cc: QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000056949005bb752804 Content-Type: text/plain; charset="UTF-8" Il mar 16 feb 2021, 15:11 Peter Maydell ha scritto: > On Tue, 16 Feb 2021 at 13:44, Paolo Bonzini wrote: > > > > On 16/02/21 14:36, Peter Maydell wrote: > > > 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'. > > > > It really depends on what the default "-M pc,nographics" arguably makes > > sense too (more so than "-M pc,graphics" since true is the default). > > Is anybody using 'pc,nographics' ? google didn't find any examples. > It's just an example that the prevalence of "nowait" over "wait" is simply because the default of "server" is false while the default of "wait" is true. Any boolean option whose default is true could benefit from a "no"-prefixed short form. But I am pretty sure that there are users in the wild for noipv4 or noipv6. > How do you propose to resolve the issues and ambiguities in the grammar? > > > > 1) due to QemuOpts not understanding types, you can specify "serial" and > > get "serial=on" instead > > We should fix this by plumbing through the type information, > so that we only allow 'foo' to mean 'foo=on' if foo is really > a boolean (or other type that specifies that it has similar behaviour). > There's already type information for non-freeform options (those where the QemuOptsList includes the list of valid suboptions, such as -smp or -m). Adding it for freeform options (-M, -device) is basically impossible since the type information comes from a mix of QAPI schema, QOM class declarations and C code. One would basically have to do an incremental visit of the schema (assuming there is a schema, and it's not just C code) during the parsing. This is understandably not something I plan to spend time on. I could change QemuOpts to allow short forms for non-freeform option groups, and turn -chardev into a non-freeform option. That would solve the immediate issue with chardev. But I agree that consistent behavior is better, so I don't think this is a good idea either. > 2) with a parser that understands other types than strings, you would > > not be able to specify "-M kernel-irqchip" because it would be converted > > to the boolean "true" and not the enum "'on'" > > We should decide whether 'kernel-irqchip' has a type that > allows 'no parameter specified' => 'use this default value' > or not, and if we go for the latter use whatever default value > the backend expects. I don't understand, the point of short-form options is to use a *non-default* value. (In other words, the affirmative short form would typically be used to specify true when the default is false). (And probably "boolean-and-an-extra-value" > types should allow the boolean bit to be specified in all the > same ways that a plain-old-boolean is.) > > 3) one is not be able to specify "-M pc" -M usb" because the second > > kernel-irqchip would be interpreted as a machine type? > > I don't understand this one, I'm afraid. > I mean that "-M pc -M usb" is parsed as "-machine type=pc -machine type=usb" and then merged into "-machine type=usb". The user would expect "-machine type=c -machine usb=on" since "-M pc -M usb=on" works. So "usb=on" cannot always be shortened to "usb", which is surprising. I think this one only affects -M though. Paolo > -- PMM > > --00000000000056949005bb752804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Il mar 16 feb 2021, 15:11 Peter Maydell <peter.maydell@linaro.org> ha scritto:
<= /div>
On Tue, 16 Feb 2021 at 13:44, Paolo Bon= zini <pbonzini@redhat.com> wrote:
>
> On 16/02/21 14:36, Peter Maydell wrote:
> > 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=3Dfalse' is much less obvious and I'm happy if w= e only
> > support it as a special-case for 'nowait'.
>
> It really depends on what the default=C2=A0 "-M pc,nographics&quo= t; arguably makes
> sense too (more so than "-M pc,graphics" since true is the d= efault).

Is anybody using 'pc,nographics' ? google didn't find any examp= les.

It's just an example that the prevalence of "nowait" over= "wait" is simply because the default of "server" is fa= lse while the default of "wait" is true. Any boolean option whose= default is true could benefit from a "no"-prefixed short form. B= ut I am pretty sure that there are users in the wild for noipv4 or noipv6.<= /div>

> How do you propose to resolve the is= sues and ambiguities in the grammar?
>
> 1) due to QemuOpts not understanding types, you can specify "seri= al" and
> get "serial=3Don" instead

We should fix this by plumbing through the type information,
so that we only allow 'foo' to mean 'foo=3Don' if foo is re= ally
a boolean (or other type that specifies that it has similar behaviour).
=

Ther= e's already type information for non-freeform options (those where the = QemuOptsList includes the list of valid suboptions, such as -smp or -m). Ad= ding it for freeform options (-M, -device) is basically impossible since th= e type information comes from a mix of QAPI schema, QOM class declarations = and C code. One would basically have to do an incremental visit of the sche= ma (assuming there is a schema, and it's not just C code) during the pa= rsing. This is understandably not something I plan to spend time on.
<= div dir=3D"auto">
I could change QemuOpts to all= ow short forms for non-freeform option groups, and turn -chardev into a non= -freeform option. That would solve the immediate issue with chardev. But I = agree that consistent behavior is better, so I don't think this is a go= od idea either.

> 2) with a parser tha= t understands other types than strings, you would
> not be able to specify "-M kernel-irqchip" because it would = be converted
> to the boolean "true" and not the enum "'on'&qu= ot;

We should decide whether 'kernel-irqchip' has a type that
allows 'no parameter specified' =3D> 'use this default value= '
or not, and if we go for the latter use whatever default value
the backend expects.

I don't understand, the point of short-form options is = to use a *non-default* value. (In other words, the affirmative short form w= ould typically be used to specify true when the default is false).

(And probably "boolean-and-an-extra-value&qu= ot;
types should allow the boolean bit to be specified in all the
same ways that a plain-old-boolean is.)

> 3) one is not be able to specify "-M pc" -M usb" becaus= e the second
> kernel-irqchip would be interpreted as a machine type?

I don't understand this one, I'm afraid.

I mean that "-M pc -M = usb" is parsed as "-machine type=3Dpc -machine type=3Dusb" a= nd then merged into "-machine type=3Dusb". The user would expect = "-machine type=3Dc -machine usb=3Don" since "-M pc -M usb=3D= on" works. So "usb=3Don" cannot always be shortened to "= ;usb", which is surprising. I think this one only affects -M though.

Paolo


-- PMM

--00000000000056949005bb752804--