On Tue, May 15, 2007 at 09:19:07AM +0100, Russell King wrote: > On Tue, May 15, 2007 at 11:18:50AM +0900, Simon Horman wrote: > > "Remove hardcoding of hard_smp_processor_id on UP systems", > > 2f4dfe206a2fc07099dfad77a8ea2f4b4ae2140f in Linus' tree, moved > > the definition of hard_smp_processor_id linux/smp.h to asm/smp.h > > for UP systems. This causes a regression on ARM as the definition > > was not added to asm-arm/smp.h. > > > > Cc: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]> > > Signed-off-by: Simon Horman <[EMAIL PROTECTED]> > > I took an alternative approach - since Integrator never had the complete > SMP support merged, I ripped it out of that platform. Whether realview > suffers from the same thing or not I'm not sure - uniprocessor realview > is not something covered by the ARM default configuration files, and > therefore kautobuild won't check that configuration.
I can take a look into this. Is there a tree other than Linus' I should be working with? > However, the things I find annoying about this is: > > 1. asm/smp.h was _never_ included in ARM UP builds prior to this change. > 2. we have linux/smp.h and the general rule is that if asm/foo.h and > linux/foo.h are present, linux/foo.h is included in preference to > asm/foo.h > > Given the amount of janitors we now have looking at the kernel code, > (2) is a big concern - it could mean a constant stream of patches > trying to "fix" files including asm/smp.h. > > I would suggest that if there is a desire to include asm/smp.h on UP > builds, the inclusion of it by linux/smp.h is made unconditional. I was thinking that myself, though I'm kind of fearful of what kind of (additional) breakage it might cause. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/