On 01/02/2024 10:35 am, Andrew Cooper wrote: > Nothing in bitmap.h uses lib.h, and there's no point including types.h when we > need to include bitops.h anyway. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > --- > CC: George Dunlap <george.dun...@citrix.com> > CC: Jan Beulich <jbeul...@suse.com> > CC: Stefano Stabellini <sstabell...@kernel.org> > CC: Wei Liu <w...@xen.org> > CC: Julien Grall <jul...@xen.org> > --- > xen/include/xen/bitmap.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/xen/include/xen/bitmap.h b/xen/include/xen/bitmap.h > index b9f980e91930..9f749e3913d8 100644 > --- a/xen/include/xen/bitmap.h > +++ b/xen/include/xen/bitmap.h > @@ -3,8 +3,6 @@ > > #ifndef __ASSEMBLY__ > > -#include <xen/lib.h> > -#include <xen/types.h> > #include <xen/bitops.h>
Turns out this went too far, and breaks PPC. Other arches look ok. https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/6076263594 bitmap.h uses mem{set,cpy}() so needs string.h. That's a bug in this patch specifically. However, cpumask.h transitively picks up IS_ALIGNED() (so needs macros.h) and ASSERT() which sadly is still in lib.h I guess moving the mess from bitmap.h to cpumask.h is a (minor) improvement. But this comes back to the header tangle which prevented moving BUG() in the first place. Sadly there's been no reply to my question in the debugger.h removal, but I'm going to get that committed and then we can re-evaluate. ~Andrew
