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

[Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>]

On 03/03/2022 11:04, Jan Beulich wrote:
> 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.

Well - I've already audited them all once recently.  What's once more...

I'll have a go in due course; I'd definitely prefer to avoid special
casing the positive boolean form in individual handlers.

~Andrew