On 30/01/2019 16:38, Jan Beulich wrote:
>>>> On 30.01.19 at 16:55, <andrew.coop...@citrix.com> wrote:
>> Xen will warn when an unknown parameter is found in the command line. e.g.
>>
>> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>>
>> One case where this goes wrong is a workaround for an old grub bug, which
>> resulted in "placeholder" being prepended to the command line.
>>
>> Another case is when booting a CONFIG_PV_SHIM_EXCLUSIVE build, in which the
>> parsing for the "pv-shim" parameter is discarded.
>>
>> Introduce ignore_param() and OPT_IGNORE to cope with known cases, where
>> warning the user is the wrong course of action to take.
>>
>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
> Reviewed-by: Jan Beulich <jbeul...@suse.com>
>
>> An implementation detail of ignore_param() is that it can only be used once
>> per translation unit, which is fine for now. Two options to fix this are to
>> tokenise __LINE__ in (requires some extreme preprocessor magic to make work,
>> as ## inhibits expansion, and may cause livepatching issues), or to retain
>> the
>> _val parameter and require callers to just pass in a unique string.
> How about requiring the quotes to be omitted from the argument
> passed to the macro and using that string to paste onto the
> variable names? This would require following an earlier suggestion
> of mine in that we (a) treat '-' and '_' equally when parsing
> command line options (cmdline_strcmp()) and (b) the main parser
> to use that function. But as you say, nothing that needs solving
> right away.
>
>> @@ -136,6 +137,11 @@ extern const struct kernel_param __param_start[],
>> __param_end[];
>> .type = OPT_STR, \
>> .len = sizeof(_var), \
>> .par.var = &_var }
>> +#define ignore_param(_name) \
>> + __setup_str __setup_str_ign[] = _name; \
>> + __kparam __setup_ign = \
>> + { .name = __setup_str_ign, \
>> + .type = OPT_IGNORE }
> I don't suppose that I could talk you into dropping the leading
> underscore from the macro parameter name,
No. That results in a failure to compile because of ".name" when
initialising the structure.
I've left it as is for consistency with the other macros.
> and into
> reducing the double leading underscores of the variables to
> single ones?
Done.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
