Re: [Xen-devel] [PATCHv6] 27/28] build: convert CONFIG_COMPAT to Kconfig

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.12.15 at 13:52, <cardoe@xxxxxxxxxx> wrote:
> On 11/30/15 9:18 AM, Jan Beulich wrote:
>>>>> On 24.11.15 at 18:52, <cardoe@xxxxxxxxxx> wrote:
>>> ---
>>>  xen/arch/x86/Kconfig | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>> 
>> This can't be complete - you ought to be deleting the current definition.
> 
> I don't understand?

I'd expect you to delete the

#define CONFIG_COMPAT

from wherever it currently lives.

>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -25,6 +25,13 @@ config ARCH_DEFCONFIG
>>>  
>>>  menu "Architecture Features"
>>>  
>>> +config COMPAT
>>> +   def_bool y
>>> +   help
>>> +     32-bit interface support on 64-bit Xen which is used for both
>>> +     HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective
>>> +     of the destination runmode of the guest.
>> 
>> I also don't think help text is very useful here, as it won't appear
>> anywhere (and due to the hvmloader needs it's also not very
>> likely to become a user selectable option going forward).
> 
> This wasn't meant to be a user-selectable option. The help text is
> actually based on a conversation I had with Andrew Cooper on IRC. During
> the RFC of the kconfig patch series I had suggested (and it seemed like
> some liked it), that even for options that were not user facing that the
> Kconfig file, that defines the CONFIG_ variable could hold information
> about what it does since there is often a lack of information about what
> a CONFIG_ variable is for. This is my attempt at starting that. I can
> convert it to a plain comment. But it seems better to have some kind of
> documentation on these variables in one place and that place would make
> sense to be where they are defined.

Okay, that's fine if it's meant to be a general goal.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel