From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Simon Horman <horms@verge.net.au>
Cc: linux-kernel@vger.kernel.org,
Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [ARM] Fix hard_smp_processor_id compile error
Date: Tue, 15 May 2007 09:19:07 +0100 [thread overview]
Message-ID: <20070515081907.GA17611@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20070515022014.CC2A44F910@tabatha.lab.ultramonkey.org>
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 <fernando@oss.ntt.co.jp>
> Signed-off-by: Simon Horman <horms@verge.net.au>
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.
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.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
next prev parent reply other threads:[~2007-05-15 8:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-15 2:18 [ARM] Fix hard_smp_processor_id compile error Simon Horman
2007-05-15 2:59 ` Fernando Luis Vázquez Cao
2007-05-15 4:48 ` Andrew Morton
2007-05-15 4:54 ` Simon Horman
2007-05-15 5:22 ` Andrew Morton
2007-05-15 5:28 ` Simon Horman
2007-05-15 8:19 ` Russell King [this message]
2007-05-15 9:09 ` Simon Horman
2007-05-15 9:49 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070515081907.GA17611@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=fernando@oss.ntt.co.jp \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.