[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 1/5] ppc64: Express dependencies of 'pseries
Re: [Qemu-devel] [RFC PATCH 1/5] ppc64: Express dependencies of 'pseries' and 'powernv' machines with kconfig
Wed, 30 Jan 2019 11:15:08 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
On 30/01/19 11:02, Thomas Huth wrote:
>> I think the two approaches are more or less equivalent, but
>> "#CONFIG_FOO=n" has a small advantage when the feature has a build-time
>> dependency, such as CONFIG_MILKYMIST_TMU2's dependency on OpenGL. In
>> that case,
>> would report a contradiction if OpenGL is not available at build time, while
>> default y
>> would not.
> I somehow dislike the idea of adding lines that are commented out by
> default. For example, if someone later renames or removes the config
> switch in the Kconfig files, the comment could stay there without being
> noticed, while a CONFIG_XXX=y would cause a clean build failure if the
> option is not available anymore.
I agree. On the other hand I don't see another solution for the
MILKYMIST_TMU2 and QXL cases, and consistency is a plus too.
How often are config switches renamed or removed, especially
user-visible optional devices though? I see CONFIG_MEM_DEVICE,
CONFIG_PCI_APB, CONFIG_LIBDECNUMBER, CONFIG_XEN_I386,
CONFIG_MIPS_BOSTON, CONFIG_PIIX_PCI, CONFIG_ISA_MMIO, CONFIG_ICC_BUS
over the last few years but none probably would have been optional
devices in default-configs/ but rather in Kconfig files.
(Long term default-configs/ should probably be built automatically,
possibly by adding a description field to the Kconfig files, and that
would also ameliorate the issue you describe).
[Qemu-devel] [RFC PATCH 5/5] ppc: Express dependencies of the embedded machines with kconfig, Thomas Huth, 2019/01/30
[Qemu-devel] [RFC PATCH 2/5] ppc: Express dependencies of the 'prep' and '40p' machines with kconfig, Thomas Huth, 2019/01/30