[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/cmdline: Interpret 'vpmu' as a positive boolean


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 3 Mar 2022 12:04:04 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FppL73j/xqsPUYy46Btn0R/6oKYrGNrgVQKpuFBJZkE=; b=nRXYRjMcYhajZobn7Xj067TmBjJeMEVabAobxmzsIzvblNu7+XeLYhasQ9VfR2pvJZZ6HH7l86kshsFoRyKAzJGQZDiVqiMKLIecMhBxsavphBT5NtVhDfMpB3ES3oA6aFStCsNHt+rVurU+q+5D2+ZdjRHmHPeb/3twLQ4935V5JREXbcP+7530mrAozm4OtPwFofALDuI4KiJj4gMwanNCrB6GX3NPodtfZ9LXsFtdTfydn763hvm7vQ3M42huZ7AloldH9lzFklNmCsOYFypd2ky/r4lgoJnsCXYA3FjY9NlTWyA8r2sINIwmUab3HGU7Yx9RmFeVl2jC0c/Omw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pg0nuAWBrv7vTrQRnlyvnSQXgOna1bc0LQ0fnJsNzjhLKUP0b8UTbRnDdGSQ7JtEJo3PY0v0Au3MLTS8lSAs/sBvi8aLLn2jnplPDgHm9BpT7LACHuq5kFQJBFXA6calnto6e8QIEVkjqZmiDjZVj69CAzKkzLjzC/rXcEurpA0ghRnYNHrH8YIGffmXyhwlqBt6rmX573j3Avm0FU3PYXjNCyaVFYpJAhx+1lmFjmvNTeBNu3A3ihOEO/Z0czSYQhdHUpmvByGJi4HCM1Tlar+4hfMfNqzpQrIvxkjaJnBj0vG8UVeGghlyNlETv6gQj2k+Tl2qyJGX6PjfZYcAJw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 03 Mar 2022 11:04:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.03.2022 11:48, Andrew Cooper wrote:
> On 03/03/2022 07:44, Jan Beulich wrote:
>> On 02.03.2022 23:11, Andrew Cooper wrote:
>>> This makes it behave slightly more like a regular boolean option.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>>> Slightly RFC, because there is no easy way of making the opposite "normal
>>> boolean" case work for no-vpmu.
>> There's nothing to do to make this work afaict: Generic command line
>> handling converts "no-<option>" to "<option>=no" for custom params.
> 
> Oh - I'd forgotten that, in which case this patch actually wants to be
> simply:
> 
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index adff2d2c77f3..2cea1da781ac 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -162,6 +162,11 @@ static int parse_params(const char *cmdline, const
> struct kernel_param *start,
>                      safe_strcpy(opt, "no");
>                      optval = opt;
>                  }
> +                else if ( !*optval )
> +                {
> +                    safe_strcpy(opt, "1");
> +                    optval = opt;
> +                }
>                  rctmp = param->par.func(optval);
>                  break;
>              case OPT_IGNORE:
> 
> to turn "option\0" into "option=1", no?

Iirc extending this to the positive case was deliberately not done, for
the risk of breaking custom handlers not expecting the standard boolean
forms. We could likely go this route, but only after auditing all custom
handlers, I'm afraid.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.