On 19.05.2023 17:24, Andrew Cooper wrote: > On 17/05/2023 3:01 pm, Jan Beulich wrote: >> On 16.05.2023 16:53, Andrew Cooper wrote: >>> --- a/xen/arch/x86/include/asm/cpufeature.h >>> +++ b/xen/arch/x86/include/asm/cpufeature.h >>> @@ -7,6 +7,7 @@ >>> #define __ASM_I386_CPUFEATURE_H >>> >>> #include <xen/const.h> >>> +#include <xen/stdbool.h> >>> #include <asm/cpuid.h> >> This isn't needed up here, and ... >> >>> @@ -17,7 +18,6 @@ >>> #define X86_FEATURE_ALWAYS X86_FEATURE_LM >>> >>> #ifndef __ASSEMBLY__ >>> -#include <xen/bitops.h> >> ... putting it here would (a) eliminate a header dependency for >> assembly sources including this file (perhaps indirectly) and (b) >> eliminate the risk of a build breakage if something was added to >> that header which isn't valid assembly. > > b) That's a weak argument for headers in general, but you're saying it > about our copy of stdbool.h which probably the least likely header for > that ever to be true. > > a) Not really, because cpuid.h pulls in a reasonable chunk of the world, > including types.h and therefore stdbool.h. cpuid.h is necessary to make > the X86_FEATURE_ALWAYS -> X86_FEATURE_LM, which is used by asm for > alternatives. > > I'm tempted to just omit it. cpufeature.h has one of the most tangled > set of headers we've got, and I can't find any reasonable way to make it > less bad.
Yeah, omitting would certainly be fine with me. Jan
