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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

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