Re: [Xen-devel] [PATCH v2 for-4.12] xen/cmdline: Work around some specific command line warnings

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.01.19 at 16:55, <andrew.cooper3@xxxxxxxxxx> 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.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

> 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, and into
reducing the double leading underscores of the variables to
single ones? I realize this won't fit the other macros, but
eventually we will want to get rid of all those name space
violations.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel