From: Ian Campbell <ian.campbell@citrix.com>
To: Doug Goldstein <cardoe@cardoe.com>, xen-devel@lists.xen.org
Subject: Re: [RFC 00/29] Incomplete Kconfig conversion
Date: Tue, 6 Oct 2015 14:05:48 +0100 [thread overview]
Message-ID: <1444136748.5302.160.camel@citrix.com> (raw)
In-Reply-To: <1444082620-3253-1-git-send-email-cardoe@cardoe.com>
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.
next prev parent reply other threads:[~2015-10-06 13:05 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 22:03 [RFC 00/29] Incomplete Kconfig conversion Doug Goldstein
2015-10-05 22:03 ` [RFC 01/29] build: import Kbuild/Kconfig from Linux 4.2 Doug Goldstein
2015-10-06 12:45 ` Jan Beulich
2015-10-06 16:00 ` Doug Goldstein
2015-10-06 16:47 ` Doug Goldstein
2015-10-07 6:32 ` Jan Beulich
2015-10-07 8:19 ` Ian Campbell
2015-10-07 8:23 ` Andrew Cooper
2015-10-07 9:54 ` Jan Beulich
2015-10-07 10:02 ` Ian Campbell
2015-10-05 22:03 ` [RFC 02/29] build: trim down Linux bits Doug Goldstein
2015-10-06 12:42 ` Jan Beulich
2015-10-06 16:02 ` Doug Goldstein
2015-10-06 16:15 ` Ian Campbell
2015-10-06 16:42 ` Doug Goldstein
2015-10-06 16:52 ` Ian Campbell
2015-10-05 22:03 ` [RFC 03/29] build: hookup initial Kconfig usage Doug Goldstein
2015-10-06 9:58 ` Andrew Cooper
2015-10-06 12:36 ` Jan Beulich
2015-11-10 23:00 ` Doug Goldstein
2015-11-11 8:57 ` Jan Beulich
2015-10-06 12:53 ` Jan Beulich
2015-10-05 22:03 ` [RFC 04/29] build: include config bits to build with Doug Goldstein
2015-10-05 22:03 ` [RFC 05/29] build: convert HAS_PASSTHROUGH use to Kconfig Doug Goldstein
2015-10-06 9:47 ` Andrew Cooper
2015-10-06 12:38 ` Jan Beulich
2015-10-06 15:47 ` Doug Goldstein
2015-10-05 22:03 ` [RFC 06/29] build: convert HAS_DEVICE_TREE " Doug Goldstein
2015-10-05 22:03 ` [RFC 07/29] build: convert HAS_PCI " Doug Goldstein
2015-10-05 22:03 ` [RFC 08/29] build: convert HAS_NS16550 " Doug Goldstein
2015-10-05 22:03 ` [RFC 09/29] build: convert HAS_IOPORTS " Doug Goldstein
2015-10-05 22:03 ` [RFC 10/29] build: convert HAS_ACPI " Doug Goldstein
2015-10-05 22:03 ` [RFC 11/29] build: convert HAS_VIDEO " Doug Goldstein
2015-10-05 22:03 ` [RFC 12/29] build: convert HAS_VGA " Doug Goldstein
2015-10-05 22:03 ` [RFC 13/29] build: convert HAS_CPUFREQ " Doug Goldstein
2015-10-05 22:03 ` [RFC 14/29] build: convert HAS_GDBSX " Doug Goldstein
2015-10-05 22:03 ` [RFC 15/29] build: convert HAS_PDX " Doug Goldstein
2015-10-05 22:03 ` [RFC 16/29] build: convert HAS_KEXEC " Doug Goldstein
2015-10-05 22:03 ` [RFC 17/29] build: convert HAS_ARM_HDLCD " Doug Goldstein
2015-10-05 22:03 ` [RFC 18/29] build: convert HAS_CADENCE_UART " Doug Goldstein
2015-10-05 22:03 ` [RFC 19/29] build: convert HAS_PL011 " Doug Goldstein
2015-10-05 22:03 ` [RFC 20/29] build: convert HAS_EXYNOS4210 " Doug Goldstein
2015-10-05 22:03 ` [RFC 21/29] build: convert HAS_OMAP " Doug Goldstein
2015-10-05 22:03 ` [RFC 22/29] build: convert HAS_SCIF " Doug Goldstein
2015-10-05 22:03 ` [RFC 23/29] build: convert HAS_EHCI " Doug Goldstein
2015-10-05 22:03 ` [RFC 24/29] build: convert HAS_MEM_ACCESS " Doug Goldstein
2015-10-05 22:03 ` [RFC 25/29] build: convert HAS_MEM_PAGING " Doug Goldstein
2015-10-05 22:03 ` [RFC 26/29] build: convert HAS_MEM_SHARING " Doug Goldstein
2015-10-05 22:03 ` [RFC 27/29] build: convert HAS_GICV3 " Doug Goldstein
2015-10-05 22:25 ` Julien Grall
2015-10-06 9:56 ` George Dunlap
2015-10-06 10:02 ` Julien Grall
2015-10-06 10:03 ` George Dunlap
2015-10-06 10:23 ` Ian Campbell
2015-10-06 15:43 ` Doug Goldstein
2015-10-05 22:03 ` [RFC 28/29] build: convert CONFIG_COMPAT " Doug Goldstein
2015-10-05 22:03 ` [RFC 29/29] build: convert kexec options to CONFIG_KEXEC Doug Goldstein
2015-10-05 22:12 ` [RFC 00/29] Incomplete Kconfig conversion Julien Grall
2015-10-06 15:49 ` Doug Goldstein
2015-10-05 23:47 ` Doug Goldstein
2015-10-06 9:39 ` Andrew Cooper
2015-10-06 9:41 ` Andrew Cooper
2015-10-06 10:15 ` Julien Grall
2015-10-06 10:21 ` Andrew Cooper
2015-10-06 13:05 ` Ian Campbell [this message]
2015-10-06 15:58 ` Doug Goldstein
2015-10-06 16:11 ` Ian Campbell
2015-11-09 15:06 ` Konrad Rzeszutek Wilk
2015-11-09 18:16 ` Doug Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1444136748.5302.160.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=cardoe@cardoe.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).