Re: [PATCH] x86: wrap kexec feature with CONFIG_KEXEC

[Jonathan Creekmore <jonathan.creekmore@gmail.com>]

Andrew Cooper <andrew.cooper3@citrix.com> writes:

> On 01/09/15 11:54, Jan Beulich wrote: 
>>>>> On 01.09.15 at 12:44, <andrew.cooper3@citrix.com> wrote: 
>>> On 01/09/15 11:36, Ian Campbell wrote: 
>>>> In general (i.e. not 100% consistently, I think) we have 
>>>> tended to avoid making things user-facing compile time 
>>>> options. Many of the existing CONFIG_* and HAVE_* are really 
>>>> about things which are arch dependent, or require specific 
>>>> porting to each arch etc. I think the KEXEC flag is one of 
>>>> those. 
>>>> 
>>>> This keeps the test matrix more reasonable (unlike 
>>>> e.g. Linux's Kconfig) and also helps us by ensuring that 
>>>> users are mostly running one of a small number of possible 
>>>> configs. 
>>>> 
>>>> I slightly fear that after Kexec you are going to want to 
>>>> strip out more and more stuff... 
>>> I for one welcome a Kconfig style approach.  We will never be 
>>> in the same order of magnitude of options as Linux, and it 
>>> will help to properly modularise the code. 
>> Indeed the idea was brought up a few times already, and I would 
>> also welcome such a step (accepting the downside of the larger 
>> test matrix). Not the least considering the "no shadow mode" 
>> and "big memory" build options that got introduced not so long 
>> ago. 
> 
> From a large attack surface point of view, support for 32bit ABI 
> on 64bit Xen is a welcome candidate for more controlled 
> environments. 
> 
> From a code volume point of view, having things like PV or 
> support configurable would be interesting. 

I am not interested in unnecessarily stripping out more and more 
code. However, I do want to reduce the number of features and 
backwards-compatibility code-paths that are compiled into my 
build. Areas like the 32-bit ABI on 64-bit Xen like Andrew 
mentioned or the legacy Xenlinux ABI are paths that I am 
interested in pruning. One area I have a preliminary patch for is 
selectively compiling individual scheduling algorithms in, giving 
me the option to compile out the experimental algorithms from my 
build.

Obviously, I can carry my own patchqueues for these types of changes, but
I would prefer to upstream them where possible.