[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 08/10] arm: add QEMU, Rcar3 and MPSoC configs
On 06/01/2018 09:51 PM, Stefano Stabellini wrote: On Fri, 1 Jun 2018, Julien Grall wrote:Hi Stefano, Sorry for formatting. On Thu, 31 May 2018, 22:50 Stefano Stabellini, <sstabellini@xxxxxxxxxx> wrote: Add a "Platform Support" menu with three umbrella kconfig options: QEMU, RCAR3 and MPSOC. They enable the required options for their hardware platform. This patch is nothing close to what we discussed. As far as I can tell, the tiny.config will end up to select all the platforms with their driver. It will not be possible to deselect the driver selected for a platform afterwards. I still think the best if providing a choice list where only one option can be selected. I would like to understand why you didn't go this path.Yes, sorry, I didn't explain why I did this and what I told you on the call was wrong, adding to the confusion. First, it is true that `make olddefconfig' is run automatically on any make target. Except for `make menuconfig', that's special. If you copy a partial config (like tiny.config) to .config, then execute `make menuconfig', the menu gets automatically populated with the missing values using defaults (as if olddefconfig was run), but it won't automatically save them to file (fortunately!!). That means that all the platform options below (QEMU, RCAR3, MPSOC) will show as selected in the menu, but if the user deselects two of them, for instance QEMU and RCAR3, the result is that *only* MPSOC and related options will be written down to the .config. The kconfig infrastructure is not as bad as I initially thought :-) In short, the following steps work: - copy tiny.config to .config - make menuconfig -> deselect QEMU and RCAR3, save .config IHMO, this is really fragile. As you said most of the command will run "make oldconfig" automatically. This is also quite natural for a Linux user to do a "make oldconfig" after copying the .config. So I think we should be able to cater everyone here rather than one "odd" solution. You seem to have misunderstood my suggestion on previous version. I answered there and would appreciate if you have another look. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |