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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
