recent major -unstable changes cause ia64 build to be broken

recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

It looks like the recent changes to update
to base off of 2.6.11 rather than 2.4 has badly
broken the ia64 build.  I'm still looking to figure
out exactly what is wrong but it doesn't look easy.

I'm all for doing this but:
1) Shouldn't such a major change that affects so many
   common files be done in a staging tree to ensure
   other archs don't break before putting it in
   unstable?
2) Is it really necessary to change the indentation of
   otherwise unchanged (I think) Linux files?  (see
   bitops.h)

Note that Xen/ia64 has included many of the new
Linux files for some time... I put them in an
include/asm-ia64/linux subdirectory and compiles
are done with -I.../include/asm-ia64 to resolve
the #include <linux/xxx.h> lines.  Perhaps something
similar could/should be done for x86 at least until
all the potential conflicts can be sorted out.

Dan

P.S. Perhaps now is a good time to install and try the
x86->ia64 cross-compiler?

Re: recent major -unstable changes cause ia64 build to be broken

[Keir Fraser]

On 10 May 2005, at 20:16, Magenheimer, Dan (HP Labs Fort Collins) wrote:

> It looks like the recent changes to update
> to base off of 2.6.11 rather than 2.4 has badly
> broken the ia64 build.  I'm still looking to figure
> out exactly what is wrong but it doesn't look easy.

The most pertinent changes are:
  1. Upgrade ACPI common code from Linux 2.6.11
  2. Remove PCI code

There are a few others (e.g., starting slowly to move to Linux's 
cpumask_t), but I think they are unlikely to be difficult to fix for. 
Certainly they have resulted in very few changes to files in 
include/xen.

Change (1) ought not to be too difficult to fix for ia64 as most of 
your code is 2.6-based already. I just pulled the 2.6.11 x86-specific 
acpi source files into Xen and tweaked them a very small amount to get 
them to build.

Change (2) is also likely very easy, since you say you leave most 
hardware setup to domain0 anyway. I doubt you need to do PCI 
enumeration or scanning in Xen itself? Culling you in-Xen PCI code 
entirely is probably the best way forward.

  -- Keir

RE: recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

Thanks, that was very helpful.

The biggest problem was due to the removal of three
includes from include/xen/slab.h... this was obscured
by some of the other changes.

Could you put these back in where they were before please?
(If necessary, with a ifdef ia64 for now and we can sort
it out later.)

< #include <xen/mm.h>
< #include <xen/cache.h>
< #include <xen/types.h> 

Actually, it appears I only need xen/mm.h if that helps.

Thanks,
Dan

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
> Sent: Tuesday, May 10, 2005 2:17 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-devel
> Subject: Re: [Xen-devel] recent major -unstable changes cause 
> ia64 build to be broken
> 
> 
> On 10 May 2005, at 20:16, Magenheimer, Dan (HP Labs Fort 
> Collins) wrote:
> 
> > It looks like the recent changes to update
> > to base off of 2.6.11 rather than 2.4 has badly
> > broken the ia64 build.  I'm still looking to figure
> > out exactly what is wrong but it doesn't look easy.
> 
> The most pertinent changes are:
>   1. Upgrade ACPI common code from Linux 2.6.11
>   2. Remove PCI code
> 
> There are a few others (e.g., starting slowly to move to Linux's 
> cpumask_t), but I think they are unlikely to be difficult to fix for. 
> Certainly they have resulted in very few changes to files in 
> include/xen.
> 
> Change (1) ought not to be too difficult to fix for ia64 as most of 
> your code is 2.6-based already. I just pulled the 2.6.11 x86-specific 
> acpi source files into Xen and tweaked them a very small 
> amount to get 
> them to build.
> 
> Change (2) is also likely very easy, since you say you leave most 
> hardware setup to domain0 anyway. I doubt you need to do PCI 
> enumeration or scanning in Xen itself? Culling you in-Xen PCI code 
> entirely is probably the best way forward.
> 
>   -- Keir
> 
> 

Re: recent major -unstable changes cause ia64 build to be broken

[Hollis Blanchard]

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> 
> The biggest problem was due to the removal of three
> includes from include/xen/slab.h... this was obscured
> by some of the other changes.
> 
> Could you put these back in where they were before please?
> (If necessary, with a ifdef ia64 for now and we can sort
> it out later.)
> 
> < #include <xen/mm.h>
> < #include <xen/cache.h>
> < #include <xen/types.h> 
> 
> Actually, it appears I only need xen/mm.h if that helps.

I needed to include xen/mm.h in a handful of (common) places with the
new code:
	xen/common/page_alloc.c
	xen/common/schedule.c
	xen/drivers/char/console.c

These files all use things from xen/mm.h, but do not include it. Here I
will repeat my point about relying on implicit includes... :)

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: recent major -unstable changes cause ia64 build to be broken

[Christian Limpach]

On 5/10/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> Thanks, that was very helpful.
> 
> The biggest problem was due to the removal of three
> includes from include/xen/slab.h... this was obscured
> by some of the other changes.
> 
> Could you put these back in where they were before please?
> (If necessary, with a ifdef ia64 for now and we can sort
> it out later.)
> 
> < #include <xen/mm.h>
> < #include <xen/cache.h>
> < #include <xen/types.h>
> 
> 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?

    christian

RE: recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

It looks like xen/mm.h is needed in quite a few more files for
ia64.  Can we put it back in slab.h for now and sort it out
later?  I have a user waiting to download latest bits.

> -----Original Message-----
> From: Hollis Blanchard [mailto:hollisb@us.ibm.com] 
> Sent: Tuesday, May 10, 2005 3:35 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Keir Fraser; xen-devel
> Subject: Re: [Xen-devel] recent major -unstable changes cause 
> ia64 build to be broken
> 
> Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > 
> > The biggest problem was due to the removal of three
> > includes from include/xen/slab.h... this was obscured
> > by some of the other changes.
> > 
> > Could you put these back in where they were before please?
> > (If necessary, with a ifdef ia64 for now and we can sort
> > it out later.)
> > 
> > < #include <xen/mm.h>
> > < #include <xen/cache.h>
> > < #include <xen/types.h> 
> > 
> > Actually, it appears I only need xen/mm.h if that helps.
> 
> I needed to include xen/mm.h in a handful of (common) places with the
> new code:
> 	xen/common/page_alloc.c
> 	xen/common/schedule.c
> 	xen/drivers/char/console.c
> 
> These files all use things from xen/mm.h, but do not include 
> it. Here I
> will repeat my point about relying on implicit includes... :)
> 
> -- 
> Hollis Blanchard
> IBM Linux Technology Center
> 

RE: recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

> > 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.  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.

There's another new problem in cpumask.h... I'll send that in
a separate message.

Dan

RE: recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

Another new problem due to a common change...

xen/include/xen/cpumask.h declares:

  extern cpumask_t cpu_online_map;

However, with CONFIG_SMP off, xen/include/xen/smp.h
defines cpu_online_map to 1.

I note the comment at the beginning of cpumask.h
that it will soon be replaced, but in the meantime,
please surround the extern declaration with:

  #ifndef cpu_online_map
  extern...
  #endif

Thanks,
Dan

Re: recent major -unstable changes cause ia64 build to be broken

[Christian Limpach]

On 5/10/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> 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

RE: recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

> 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...

Good idea, but no it doesn't work.  I'm at a loss to explain exactly
why, but I played with it quite a bit (e.g. putting it at the beginning
of sched.h right after the include of xen/config.h) and none of
the attempts compile.

These multi-level include dependencies are very touchy...

If you want, I can set you up with the cross-compiler and
you can play with it a bit.  That might be a good idea anyway
if more "cleanup" is planned.

Note that linux/include/linux/slab.h has many includes (though
none of them are mm.h).  What is your goal of "cleaning up"?

Thanks,
Dan

RE: recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

> it. Here I
> will repeat my point about relying on implicit includes... :)

Though I agree in principle with not using implicit includes,
it doesn't really work in reality.  For example, many
header files declare structs that use typedefs for elements
of the struct, which creates a direct dependency on a header
file.  The only way to avoid including the header file directly
in the "parent" header file is by "instructing" all the users
of the "parent" header to first include the subsidiary ones.
The C language doesn't deal with this very well, resulting
in very obscure error messages if something is missing.
And since typedefs cannot be duplicately declared even if
identical (a bug in C I think), there's a catch-22.

Dan

RE: recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

Keir --

Thanks for putting those changes in.  I have already
grabbed and tested them with latest ia64 bits.

Please pull:
bk://xen-ia64.bkbits.net/xeno-unstable-ia64.bk

and life should be happy again for ia64 users :-)

Thanks,
Dan 

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
> Sent: Tuesday, May 10, 2005 2:17 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-devel
> Subject: Re: [Xen-devel] recent major -unstable changes cause 
> ia64 build to be broken
> 
> 
> On 10 May 2005, at 20:16, Magenheimer, Dan (HP Labs Fort 
> Collins) wrote:
> 
> > It looks like the recent changes to update
> > to base off of 2.6.11 rather than 2.4 has badly
> > broken the ia64 build.  I'm still looking to figure
> > out exactly what is wrong but it doesn't look easy.
> 
> The most pertinent changes are:
>   1. Upgrade ACPI common code from Linux 2.6.11
>   2. Remove PCI code
> 
> There are a few others (e.g., starting slowly to move to Linux's 
> cpumask_t), but I think they are unlikely to be difficult to fix for. 
> Certainly they have resulted in very few changes to files in 
> include/xen.
> 
> Change (1) ought not to be too difficult to fix for ia64 as most of 
> your code is 2.6-based already. I just pulled the 2.6.11 x86-specific 
> acpi source files into Xen and tweaked them a very small 
> amount to get 
> them to build.
> 
> Change (2) is also likely very easy, since you say you leave most 
> hardware setup to domain0 anyway. I doubt you need to do PCI 
> enumeration or scanning in Xen itself? Culling you in-Xen PCI code 
> entirely is probably the best way forward.
> 
>   -- Keir
> 
> 

Re: recent major -unstable changes cause ia64 build to be broken

[Christian Limpach]

On Tue, May 10, 2005 at 03:50:52PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > 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...
> 
> Good idea, but no it doesn't work.  I'm at a loss to explain exactly
> why, but I played with it quite a bit (e.g. putting it at the beginning
> of sched.h right after the include of xen/config.h) and none of
> the attempts compile.

Did you also try putting it at the end of xen/sched.h, just before the
include of xen/slab.h?  That's the only header file which includes
xen/slab.h, everything else but xen/arch/ia64/acpi.c is common code
or x86 specific code.  I don't see how including xen/mm.h from xen/sched.h
would be different from including it from xen/slab.h, especially when it's
done at the end where all of xen/sched.h is already parsed.  Even reversing
the two includes at the end of xen/sched.h (domain.h/slab.h) should do the
trick, since domain.h also includes xen/mm.h.
 
> These multi-level include dependencies are very touchy...
> 
> If you want, I can set you up with the cross-compiler and
> you can play with it a bit.  That might be a good idea anyway
> if more "cleanup" is planned.
> 
> Note that linux/include/linux/slab.h has many includes (though
> none of them are mm.h).  What is your goal of "cleaning up"?

xen/slab.h is very small and has no includes (except config.h) and there's
nothing in there that needs xen/mm.h.  I removed the 3 additional includes
so that 3rd party source code can include xen/slab.h (to get the xmalloc
definitions) without having to pull in all of Xen's header files.

    christian

RE: recent major -unstable changes cause ia64 build to be broken

[Magenheimer, Dan (HP Labs Fort Collins)]

> Did you also try putting it at the end of xen/sched.h, just before the
> include of xen/slab.h?  That's the only header file which includes
> xen/slab.h, everything else but xen/arch/ia64/acpi.c is common code
> or x86 specific code.  I don't see how including xen/mm.h 
> from xen/sched.h
> would be different from including it from xen/slab.h, 
> especially when it's
> done at the end where all of xen/sched.h is already parsed.  
> Even reversing
> the two includes at the end of xen/sched.h (domain.h/slab.h) 
> should do the
> trick, since domain.h also includes xen/mm.h.

Yes I did try it there, as well as at the beginning and a couple
other places in the file that make sense.

When you searched for slab.h (and mm.h), you probably weren't
looking at the linux headers which get included in the Xen/ia64
build.  I think the dependency is buried deep in there somewhere.

Dan

Re: recent major -unstable changes cause ia64 build to be broken

[Hollis Blanchard]

On May 10, 2005, at 6:05 PM, Magenheimer, Dan (HP Labs Fort Collins) 
wrote:

>> it. Here I will repeat my point about relying on implicit includes... 
>> :)
>
> Though I agree in principle with not using implicit includes,
> it doesn't really work in reality.

Sorry, I strongly disagree. In this case, if every user of 
alloc_xenheap_page() had included xen/mm.h, you would not have had any 
problem.

> For example, many
> header files declare structs that use typedefs for elements
> of the struct, which creates a direct dependency on a header
> file.  The only way to avoid including the header file directly
> in the "parent" header file is by "instructing" all the users
> of the "parent" header to first include the subsidiary ones.
> The C language doesn't deal with this very well, resulting
> in very obscure error messages if something is missing.
> And since typedefs cannot be duplicately declared even if
> identical (a bug in C I think), there's a catch-22.

If a.h uses something defined in b.h, a.h must include b.h. It is a 
dependency. It's that simple.

I'm not saying recursive includes don't happen; they do. But once 
you've got that working and you explicitly include your dependencies, 
you won't see problems like this mm.h one, where changing one header 
file causes 10 loosely related files to break. Coincidentally, it also 
greatly simplifies writing a new set of header files for a new 
architecture. ;)

I suspect the source of many of your problems is due to the strange 
combination of two unrelated code bases, which makes your headers even 
more brittle than Xen/x86...

-- 
Hollis Blanchard
IBM Linux Technology Center