Andrew Cooper <andrew.coop...@citrix.com> writes:
On 01/09/15 11:54, Jan Beulich wrote:
On 01.09.15 at 12:44, <andrew.coop...@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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
