From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Creekmore Subject: Re: [PATCH] x86: wrap kexec feature with CONFIG_KEXEC Date: Tue, 01 Sep 2015 09:29:48 -0500 Message-ID: References: <1440686870-19104-1-git-send-email-jonathan.creekmore@gmail.com> <55DF2C57.8030100@citrix.com> <1441103777.27618.31.camel@citrix.com> <55E58171.80509@citrix.com> <55E5A017020000780009E87E@prv-mh.provo.novell.com> <55E584F8.2030304@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZWmZQ-0001Rw-1U for xen-devel@lists.xenproject.org; Tue, 01 Sep 2015 14:29:56 +0000 Received: by qkct7 with SMTP id t7so41933869qkc.1 for ; Tue, 01 Sep 2015 07:29:53 -0700 (PDT) In-Reply-To: <55E584F8.2030304@citrix.com> (Andrew Cooper's message of "Tue, 1 Sep 2015 11:59:04 +0100") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, keir@xen.org, Ian Campbell , Jan Beulich , David Vrabel List-Id: xen-devel@lists.xenproject.org Andrew Cooper writes: > On 01/09/15 11:54, Jan Beulich wrote: >>>>> On 01.09.15 at 12:44, 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.