[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110418123422.9341.A69D9226@jp.fujitsu.com>
Date: Mon, 18 Apr 2011 12:34:02 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: kosaki.motohiro@...fujitsu.com, Hugh Dickins <hughd@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Dave Hansen <dave@...ux.vnet.ibm.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Paul Mundt <lethal@...ux-sh.org>,
Russell King <linux@....linux.org.uk>
Subject: Re: mm: convert vma->vm_flags to 64bit
Hi
> On Sun, 2011-04-17 at 17:26 -0700, Hugh Dickins wrote:
> > I am surprised that
> > #define VM_EXEC 0x00000004ULL
> > does not cause trouble for arch/arm/kernel/asm-offsets.c,
> > but you tried cross-building it which I never did.
>
> It would probably cause trouble for a big endian ARM no ? In that case
> it should offset the load by 4.
I think you are talking two thing, VM_EXEC and offsetof(vm_flags).
Therefore I'd explain my code reading result of two.
1) VM_EXEC
arch/arm/kernel/asm-offsets.c
----------------------------------------------------------------
DEFINE(VM_EXEC, VM_EXEC);
kbuild.h
----------------------------------------------------------------
#define DEFINE(sym, val) \
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
In this case, gcc asm() statement recognize C suffix and then
we don't see compile and/or link-time error.
2) vm_flags
arch/arm/kernel/asm-offsets.c
----------------------------------------------------------------
DEFINE(VMA_VM_FLAGS, offsetof(struct vm_area_struct, vm_flags));
OK, this is risky. we have to see all of users of this.
arch/arm/mm/proc-macros.S
----------------------------------------------------------------
/*
* vma_vm_flags - get vma->vm_flags
*/
.macro vma_vm_flags, rd, rn
ldr \rd, [\rn, #VMA_VM_FLAGS]
.endm
VMA_VM_FLAGS is only used this macro. then, we only need to see
vma_vm_flags assembler macro.
Next,
% grep ENDIAN arch/arm/configs/*
arch/arm/configs/ixp2000_defconfig:CONFIG_CPU_BIG_ENDIAN=y
arch/arm/configs/ixp23xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y
arch/arm/configs/ixp4xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y
We only need to care the three subarch.
-----------------------------------------------------------
config ARCH_IXP23XX
bool "IXP23XX-based"
depends on MMU
select CPU_XSC3
select PCI
select ARCH_USES_GETTIMEOFFSET
help
Support for Intel's IXP23xx (XScale) family of processors.
config ARCH_IXP2000
bool "IXP2400/2800-based"
depends on MMU
select CPU_XSCALE
select PCI
select ARCH_USES_GETTIMEOFFSET
help
Support for Intel's IXP2400/2800 (XScale) family of processors.
config ARCH_IXP4XX
bool "IXP4xx-based"
depends on MMU
select CPU_XSCALE
select GENERIC_GPIO
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
select MIGHT_HAVE_PCI
select DMABOUNCE if PCI
help
Support for Intel's IXP4XX (XScale) family of processors.
-----------------------------------------------------------
and they are CONFIG_CPU_XSCALE or CONFIG_CPU_XSC3.
arch/arm/mm/Makefile
-----------------------------------------------------------
obj-$(CONFIG_CPU_XSCALE) += proc-xscale.o
obj-$(CONFIG_CPU_XSC3) += proc-xsc3.o
grep -c vma_vm_flags arch/arm/mm/proc-{xscale,xsc3}.S
arch/arm/mm/proc-xscale.S:0
arch/arm/mm/proc-xsc3.S:0
Then, current big endian user aren't harm from this change.
Of course, I might take mistake. I'm not arm expert. please correct
me if I'm misunderstand.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists