[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/4] x86: replace __ASM_{CL,ST}AC
On 28.07.2020 15:55, Andrew Cooper wrote: On 15/07/2020 11:48, Jan Beulich wrote:--- a/xen/arch/x86/arch.mk +++ b/xen/arch/x86/arch.mk @@ -20,6 +20,7 @@ $(call as-option-add,CFLAGS,CC,"rdrand % $(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE) $(call as-option-add,CFLAGS,CC,"xsaveopt (%rax)",-DHAVE_AS_XSAVEOPT) $(call as-option-add,CFLAGS,CC,"rdseed %eax",-DHAVE_AS_RDSEED) +$(call as-option-add,CFLAGS,CC,"clac",-DHAVE_AS_CLAC_STAC)Kconfig please, rather than extending this legacy section. Did you forget for a moment that we're still to discuss this use of Kconfig before we extend it to further instances? I'm pretty sure I gave an ack to one of the respective changes of yours only on the condition that we'd sort out whether this is indeed the way forward, without a preset outcome (and without reasoning like "let's do it because Linux does so"). That said, surely stac/clac support is old enough for us to start using unconditionally? Can't check right now, but I'm sure I wouldn't have introduced the construct if we could rely on all supported tool chains to have support for them. Could we see about sorting a reasonable minimum toolchain version, before we churn all the logic to deal with obsolete toolchains? Who's "we" here? I see you keep proposing this every once in a while, but I don't see who's going to do the work. The main reason why, while I agree we should bump the base line, I don't see myself do this is because I don't see any even just half way clear criteria by which to decide what the new level is supposed to be. Once again I don't think "let's follow what Linux does" is a suitable approach. Additionally I fear that with raising the tool chain base line, people may start considering to raise other minimum versions. While I'm personally quite fine building my own binutils and gcc (and maybe a few other pieces), I don't fancy having to rebuild, say, coreutils just to be able to build Xen. Maybe a topic for the next community call, which isn't too far out? Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |