Re: [Xen-devel] recent major -unstable changes cause ia64 build to be broken

[Christian Limpach <christian.limpach@xxxxxxxxx>]

On 5/10/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@xxxxxx> wrote:
> > > Actually, it appears I only need xen/mm.h if that helps.
> >
> > Can't you include xen/mm.h where it's needed?  Alternatively, you
> > could have asm-ia64/slab.h which includes xen/mm.h and xen/slab.h.
> > Or, why not just include it from asm-ia64/slab.h?
> 
> It appears to be needed in a lot of common files for ia64.  I am
> OK with tracking them all down but would prefer to not have that
> in the critical path right now when there is a simple fix (putting
> it back the way it was before)... unless of course that breaks x86.
> 
> There is no asm/slab.h included... __ARCH_HAS_SLAB_ALLOCATOR
> appears to be obsolete (unless Hollis is using it) since ia64
> switched over to the Rusty memory allocator.

And that's exactly why I'm reluctant to put it back -- we keep
accumulating cruft like that and even when the arch for which it was
added stops using it, the hack doesn't get cleaned up.  At least if we
indirect hacks like these through arch specific include files, it's
more likely that the hack will eventually get cleaned up...

> Adding an asm/slab.h
> back in to xen/slab.h would be another option, but no sense
> hiding the header file dependency another level deeper.

yes, except see above...  Could you check if including xen/mm.h in
ia64's apic.c file (only ia64 file including slab.h directly) and
including it at the end of xen/sched.h (before xen/slab.h gets
included) would be sufficient?  xen/sched.h is a #include-mess anyway,
so I'd rather add it there than in the now clean xen/slab.h...

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel