From: Andrew Morton <akpm@linux-foundation.org>
To: David Miller <davem@davemloft.net>
Cc: sfr@canb.auug.org.au, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, walken@google.com, riel@redhat.com
Subject: Re: linux-next: build failure after merge of the final tree (akpm tree related)
Date: Wed, 14 Nov 2012 15:09:19 -0800 [thread overview]
Message-ID: <20121114150919.19c1633a.akpm@linux-foundation.org> (raw)
In-Reply-To: <20121114.173059.2152995770988231211.davem@davemloft.net>
On Wed, 14 Nov 2012 17:30:59 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Wed, 14 Nov 2012 14:18:47 -0800
>
> > s/colour/color/
>
> The whole file uses the COLOUR spelling in it's macros, for
> consistency I see no reason not to use the same spelling
> for local variables.
>
> Else, fix the whole file instead of leaving an inconsistent
> mess around.
Sure, but which way do you want it?
Current mainline:
akpm:/usr/src/linux-3.7-rc5> grep -i colour arch/sparc/kernel/*.c arch/sparc/mm/*.c
arch/sparc/kernel/sys_sparc_32.c:#define COLOUR_ALIGN(addr) (((addr)+SHMLBA-1)&~(SHMLBA-1))
arch/sparc/kernel/sys_sparc_32.c: addr = COLOUR_ALIGN(addr);
arch/sparc/kernel/sys_sparc_32.c: addr = COLOUR_ALIGN(addr);
arch/sparc/kernel/sys_sparc_64.c:static inline unsigned long COLOUR_ALIGN(unsigned long addr,
arch/sparc/kernel/sys_sparc_64.c:static inline unsigned long COLOUR_ALIGN_DOWN(unsigned long addr,
arch/sparc/kernel/sys_sparc_64.c: addr = COLOUR_ALIGN(addr, pgoff);
arch/sparc/kernel/sys_sparc_64.c: addr = COLOUR_ALIGN(addr, pgoff);
arch/sparc/kernel/sys_sparc_64.c: addr = COLOUR_ALIGN(addr, pgoff);
arch/sparc/kernel/sys_sparc_64.c: addr = COLOUR_ALIGN(addr, pgoff);
arch/sparc/kernel/sys_sparc_64.c: unsigned long base = COLOUR_ALIGN_DOWN(addr-len, pgoff);
arch/sparc/kernel/sys_sparc_64.c: addr = COLOUR_ALIGN_DOWN(addr, pgoff);
arch/sparc/kernel/sys_sparc_64.c: addr = COLOUR_ALIGN_DOWN(addr, pgoff);
arch/sparc/kernel/sys_sparc_64.c: * 1) For file backed MAP_SHARED mmap()'s we D-cache color align,
arch/sparc/kernel/sys_sparc_64.c: int do_color_align;
arch/sparc/kernel/sys_sparc_64.c: do_color_align = 0;
arch/sparc/kernel/sys_sparc_64.c: do_color_align = 1;
arch/sparc/kernel/sys_sparc_64.c: if (do_color_align)
arch/sparc/kernel/sys_sparc_64.c: if (do_color_align)
arch/sparc/kernel/sys_sparc_64.c: if (do_color_align)
arch/sparc/kernel/sys_sparc_64.c: int do_color_align;
arch/sparc/kernel/sys_sparc_64.c: do_color_align = 0;
arch/sparc/kernel/sys_sparc_64.c: do_color_align = 1;
arch/sparc/kernel/sys_sparc_64.c: if (do_color_align)
arch/sparc/kernel/sys_sparc_64.c: if (do_color_align) {
arch/sparc/kernel/sys_sparc_64.c: if (do_color_align)
arch/sparc/kernel/sys_sparc_64.c: if (do_color_align)
arch/sparc/mm/hugetlbpage.c: * definition we don't have to worry about any page coloring stuff
arch/sparc/mm/iommu.c: /* To be coherent on HyperSparc, the page color of DVMA
arch/sparc/mm/iommu.c: iommu->usemap.num_colors = vac_cache_size >> PAGE_SHIFT;
arch/sparc/mm/iommu.c: iommu->usemap.num_colors = 1;
arch/sparc/mm/iommu.c: /* page color = pfn of page */
arch/sparc/mm/iommu.c: /* page color = physical address */
I suspect that most people expect "color". And given that this
patchset removes COLOUR_ALIGN_DOWN (and should have removed
arch/sparc/kernel/sys_sparc_32.c:COLOR_ALIGN), we end up with
--- a/arch/sparc/kernel/sys_sparc_64.c~a
+++ a/arch/sparc/kernel/sys_sparc_64.c
@@ -75,7 +75,7 @@ static inline int invalid_64bit_range(un
* the spitfire/niagara VA-hole.
*/
-static inline unsigned long COLOUR_ALIGN(unsigned long addr,
+static inline unsigned long COLOR_ALIGN(unsigned long addr,
unsigned long pgoff)
{
unsigned long base = (addr+SHMLBA-1)&~(SHMLBA-1);
@@ -113,7 +113,7 @@ unsigned long arch_get_unmapped_area(str
if (addr) {
if (do_color_align)
- addr = COLOUR_ALIGN(addr, pgoff);
+ addr = COLOR_ALIGN(addr, pgoff);
else
addr = PAGE_ALIGN(addr);
@@ -176,7 +176,7 @@ arch_get_unmapped_area_topdown(struct fi
/* requesting a specific address */
if (addr) {
if (do_color_align)
- addr = COLOUR_ALIGN(addr, pgoff);
+ addr = COLOR_ALIGN(addr, pgoff);
else
addr = PAGE_ALIGN(addr);
_
next prev parent reply other threads:[~2012-11-14 23:09 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-09 4:09 linux-next: build failure after merge of the final tree (akpm tree related) Stephen Rothwell
2012-11-14 22:18 ` Andrew Morton
2012-11-14 22:30 ` David Miller
2012-11-14 23:09 ` Andrew Morton [this message]
2012-11-14 23:10 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2013-06-06 7:25 Stephen Rothwell
2013-06-06 7:15 Stephen Rothwell
2013-06-06 6:18 Stephen Rothwell
2013-03-04 3:28 Stephen Rothwell
2013-03-04 9:22 ` Jan Kara
2013-03-04 3:10 Stephen Rothwell
2013-03-06 23:52 ` Andrew Morton
2013-01-24 5:54 Stephen Rothwell
2013-01-24 10:30 ` Shaohua Li
2013-01-24 23:22 ` Stephen Rothwell
2013-01-21 6:08 Stephen Rothwell
2013-01-21 7:17 ` Tang Chen
2012-11-09 4:16 Stephen Rothwell
2012-11-09 3:58 Stephen Rothwell
2012-11-09 4:01 ` Andrew Morton
2012-11-12 0:00 ` Stephen Rothwell
2012-09-17 11:49 Stephen Rothwell
2012-09-13 8:11 Stephen Rothwell
2012-09-13 13:24 ` David Fries
2012-09-13 13:34 ` Stephen Rothwell
2012-09-14 4:20 ` David Fries
2012-09-13 8:01 Stephen Rothwell
2012-09-13 10:01 ` Shaohua Li
2012-09-13 12:29 ` Stephen Rothwell
2012-05-11 6:20 Stephen Rothwell
2012-03-14 23:44 Stephen Rothwell
2012-02-17 10:20 Stephen Rothwell
2012-02-17 12:06 ` Konstantin Khlebnikov
2012-02-19 23:04 ` Stephen Rothwell
2012-02-19 23:15 ` Andrew Morton
2012-02-17 5:30 Stephen Rothwell
2012-02-17 6:07 ` Benjamin Herrenschmidt
2012-01-20 2:02 Stephen Rothwell
2011-12-17 4:42 Stephen Rothwell
2011-12-17 5:02 ` NeilBrown
2011-11-30 4:52 Stephen Rothwell
2011-11-30 5:40 ` David Miller
2011-11-30 6:07 ` Andrew Morton
2011-11-30 11:48 ` Neil Horman
2011-11-30 4:42 Stephen Rothwell
2011-11-30 5:16 ` Andrew Morton
2011-10-05 8:23 Stephen Rothwell
2011-09-30 1:52 Stephen Rothwell
2011-09-28 10:01 Stephen Rothwell
2011-07-27 3:55 Stephen Rothwell
2011-07-01 5:45 Stephen Rothwell
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=20121114150919.19c1633a.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=riel@redhat.com \
--cc=sfr@canb.auug.org.au \
--cc=walken@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).