Re: [PATCH v5 03/10] x86: determine HAVE_AS_* just once

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.03.2020 22:12, Andrew Cooper wrote:
> On 24/03/2020 12:33, Jan Beulich wrote:
>> With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
>> generated header instead of (at least once per [sub]directory) into
>> CFLAGS. This results in proper rebuilds (via make dependencies) in case
>> the compiler used changes between builds. It additionally eases
>> inspection of which assembler features were actually found usable.
>>
>> Some trickery is needed to avoid header generation itself to try to
>> include the to-be/not-yet-generated header.
>>
>> Since the definitions in generated/config.h, previously having been
>> command line options, might even affect xen/config.h or its descendants,
>> move adding of the -include option for the latter after inclusion of the
>> per-arch Rules.mk. Use the occasion to also move the most general -I
>> option to the common Rules.mk.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Given the work of Anthony's which is already committed in staging, I'd
> really prefer this patch to look something like
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=WIP.x86/asm&id=95ef9f80ed6359e89f988121521c421b7e9528de
> 
> That avoids all fragile games with includes, and is the position we want
> to be in, longterm.

I've thought about this some more, and not just because of the issue
with tool chain updates (or downgrades) I'm not convinced this is the
way to go, irrespective of whether Linux does. I've gone through
Linux'es Kconfig documentation again, and I couldn't find a hint that
this is supposed to cover other than user choices. Determining tool
chain capabilities at build (rather than configure) time seems quite
a bit more reliable to me. IOW there ought to be a clear distinction
between "what kind of kernel [or hypervisor] do I want" and "how does
the kernel [hypervisor] get built".

When it comes to certain user choices requiring certain tool chain
capabilities, then the help text should point this out and the build
should probably be made fail if the prereqs aren't met (alternatively
behavior like that of our xen.efi building could be chosen, with a
warning issued during the build process).

If we (and perhaps also they) clearly stated that the intention is
to also latch system properties (like userland ./configure would do),
and if the intended behavior was clearly spelled out when it comes
to any of those latched properties changing, then I might change my
opinion.

Jan