On 30/01/2019 10:01, Andrew Cooper wrote:
> On 30/01/2019 09:57, Jan Beulich wrote:
>>>>> On 29.01.19 at 20:07, <andrew.coop...@citrix.com> 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.)
>
> I can't think of any cleaner solution.

Actually, I could move this to the bottom of the file, and just undef
pv_shim.

~Andrew

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

Reply via email to