Re: [Xen-devel] [PATCH] x86/pv-shim: Avoid a command line parameter warning for CONFIG_PV_SHIM_EXCLUSIVE builds

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.01.19 at 11:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 30/01/2019 09:57, Jan Beulich wrote:
>>>>> On 29.01.19 at 20:07, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/pv/shim.c
>>> +++ b/xen/arch/x86/pv/shim.c
>>> @@ -40,7 +40,11 @@
>>>  #undef virt_to_mfn
>>>  #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
>>>  
>>> -#ifndef CONFIG_PV_SHIM_EXCLUSIVE
>>> +#ifdef CONFIG_PV_SHIM_EXCLUSIVE
>>> +/* Tolerate "pv-shim" being passed to a CONFIG_PV_SHIM_EXCLUSIVE 
>>> hypervisor. */
>>> +static bool _discard;
>>> +boolean_param("pv-shim", _discard);
>>> +#else
>>>  bool pv_shim;
>>>  boolean_param("pv-shim", pv_shim);
>>>  #endif
>> It would end up being less extra code if you did
>>
>> #ifdef CONFIG_PV_SHIM_EXCLUSIVE
>> /* Tolerate "pv-shim" being passed to a CONFIG_PV_SHIM_EXCLUSIVE hypervisor. 
>> */
>> static bool __initdata pv_shim;
>> #else
>> bool pv_shim;
>> #endif
>> boolean_param("pv-shim", pv_shim);
> 
> Sadly not.  In the EXCLUSIVE case, pv_shim is defined to be 1, and then
> you've got an object named with just a number.  (I tried this approach
> first.)

Oh, that's unfortunate in this particular case. In which case I
don't have any better suggestion either. One that you and others
perhaps wouldn't like would be

custom_param("pv-shim", NULL);

with parse_params() suitably adjusted to avoid the call in that
case.

Jan



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