Re: [Xen-devel] [RFC 00/29] Incomplete Kconfig conversion

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 10/6/15 8:05 AM, Ian Campbell wrote:
> On Mon, 2015-10-05 at 17:03 -0500, Doug Goldstein wrote:
>> Ultimately my goal is to allow for more parts of the hypervisor to be turned
>> off at compile time and potentially make it easier to include more
>> experimental features by others which can be turned off by default. Also to
>> provide the one true location for all possible knobs in the source code.
> 
> I'm OK with the switch to Kconfig generally but I'd like us to start with a
> conversion which offers the exact same set of options as exist today in the
> Makefile (i.e. not very many at all) and where the use of select and etc
> means that anyone who asks Kconfig to generate the default config (i.e. not
> an explicit defconfig file) will produce a binary with the exact same
> feature set as today. (Sorry if I misunderstood whether that is the goal
> with this initial series vs. your ultimate goal)
> 
> IOW we start by treating Kconfig as a better way for _developers_ to
> control the configuration of Xen at compile time than adding and removing
> #defines (i.e. the one true location thing you mention) but not (yet) as a
> way to let users produce a wide variety of different images.
> 
> Then we can start to consider patches which make options available for
> users, on a case by case basis.
> 
> Maybe those options should be behind some sort of dependency gate which
> means that explicit action is needed in order to deviating from the
> defaults such that it is acknowledged by the user that they have done so
> and that such configurations may not even build let alone work.
> 
> I'd also like to propose that we consider having a strict requirement for
> patches to the test infrastructure to exercise any new user-facing option
> before we accept the patch implementing it.
> 
> What I don't want to see is fragmentation where every distro does something
> subtly different or normal users ending up with different configurations to
> the norm. By "normal users" I mean those without specialised requirements
> or environments who aren't willing/able to support their decision to step
> off the beaten path.
> 
> Ian.
> 

Ian,

You stated this better than I did. My goal is not to necessarily make
this like the Linux kernel where users toggle on different bits at a
whim but more for developers and companies shipping Xen, basically those
with specialized environments could use this to upstream more code and
have it disabled by default.

The current patchset only exposes KEXEC as a user facing option because
its currently a user facing option in the source tree. I would not
expand the list of user facing options past that. I consider adding more
outside of the scope of this work and something that would happen after
this series lands on a case by case basis.

My ultimate goal with this initial work is to get all the developer
knobs in one place because currently they are spread around as Makefile
defines or defines in a header file and get a little bit of code
comments around them.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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