On 30/01/2019 17:07, Andrew Cooper wrote:
> On 30/01/2019 16:31, Juergen Gross wrote:
>> On 30/01/2019 16:55, Andrew Cooper 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>
>>> ---
>>> CC: Jan Beulich <jbeul...@suse.com>
>>> CC: Wei Liu <wei.l...@citrix.com>
>>> CC: Roger Pau Monné <roger....@citrix.com>
>>> CC: Juergen Gross <jgr...@suse.com>
>>>
>>> v2:
>>>  * Rewrite from scratch, following Juergen's suggestion
>>>
>>> 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.
>> Or make the unique string an optional parameter via:
>>
>> #define ignore_param(_name, uniq...)                \
>>     __setup_str __setup_str_ign ## uniq[] = _name;  \
>>     __kparam __setup_ign ## uniq =                  \
>>         { .name = __setup_str_ign ## uniq,          \
>>           .type = OPT_IGNORE }
>>
>> With or without that change:
>>
>> Reviewed-by: Juergen Gross <jgr...@suse.com>
>> Release-acked-by: Juergen Gross <jgr...@suse.com>
> Actually I like this as an option.

Sadly, it doesn't work, as you end up with:

__setup_str setup_str_ign_ ## [] = "pv-shim";

and ## is a binary operator.

I'll leave it as-was and we can figure this out in the future if necessary.

~Andrew

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

Reply via email to