Re: [PATCHv6] 00/28] Kconfig conversion

[Doug Goldstein <cardoe@cardoe.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3802 bytes --]

On 11/24/15 11:51 AM, Doug Goldstein wrote:
> The following series is a follow on to the Kconfig conversion patch series.
> There are still more components to convert however this is the bare minimal
> to get everything working and get the options out of the existing makefiles.
> 
> The CONFIG_HAS_ variables are there to match the behavior of the Linux
> CONFIG_HAVE_ variables. The purpose is to say that this hardware/profile/env
> supports this option while the CONFIG_ variable states that this option was
> requested on/off by user intervention.
> 
> The UARTs are now uniformly prefixed as CONFIG_UART_ and dropping most of the
> CONFIG_HAS_ labeling for them. This means they are now user selectable as
> requested by Julien Grall in the prior review. The question I've got is
> the old config was just for selecting defaults. Users could enable the OMAP
> UART for arm64 for example but I'm not sure if that's valid. Currently this
> patchset makes those UARTs not user selectable if they were not previously
> defaulted on. But I would like some feedback on this if possible.
> 
> 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.
> 
> The patch series can be grabbed at:
> https://github.com/cardoe/xen/tree/kconfig_v6
> 
> Changes since v5:
> - added Andrew Cooper's Acked-by and Tested-by
> - rebased to resolve conflict with NUMA changes in staging (minor conflict)
> 
> Changes since v4:
> - v4 was an oops and was a resend of v3. So the 'Changes since v3' apply here.
> 
> Changes since v3:
> - fix dependency inversion causing options to appear to flip back on (hi kexec)
> - separate out wiring up Kconfig and then using it in the build (added patch 3)
> - dropped the old patch 3
> - changed UART configs to be prefixed as CONFIG_UART_
> - changed ARM UART defaults
> 
> Changes since v2:
> - drop x86_32 support (patch 2)
> - fix make defconfig (patch 2)
> - fix 'make -C xen' vs 'cd xen && make' behaving differently (patch 2)
> - fix for ARM64 builds (added patch 3)
> - At this point all targets are tested on x86_64, arm32, and arm64 with
>   fresh clones and rebuilds.
> 
> Changes since v1:
> - hopefully addressed all review comments
> - added CCs to all maintainers from get_maintainer.pl as requested
> - drop Kbuild to build Kconfig and instead port the Makefile to the Xen env
> - add support for xconfig/gconfig
> - include Kconfig docs from Linux
> 

All,

There's been quite a few comments on this series and I'll admit I'm a
bit lost as to the requested direction for the series so just to clear
things up I'm going to send this out and address all the items before
the next repost. My goal is to save you all time as reviewers so that
hopefully you'll only have to review one more series.

1. Remove the KEXEC patch from this series and add it to the follow-on
series?

2. Drop UART changes and just go back to the mechanical changes that
enable the UARTs on ARM as they are today. The early patches failed to
remove the items from config/arm{32,64}.mk but remedy that.

3. sync the (A) entire linux/scripts/kconfig directory or (B) basics
from linux/scripts/kconfig or (C) basics + frontends for future series
when user-configurable options are presented. Note: Option B will
require not just copying files but making modifications (read: forking)
until a more complete copy is brought over.

4. Should I rename xen/scripts/kconfig to xen/tools/kconfig?

5. Should I drop as much $(BASEDIR) usage as possible?

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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