Re: [Xen-devel] [PATCH] x86: wrap kexec feature with CONFIG_KEXEC

[Jonathan Creekmore <jonathan.creekmore@xxxxxxxxx>]

Andrew Cooper <andrew.cooper3@xxxxxxxxxx> writes:

> On 01/09/15 11:54, Jan Beulich wrote: 
> > > > > On 01.09.15 at 12:44, <andrew.cooper3@xxxxxxxxxx> 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.

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