Skip to contentSkip to conversation

How should we do a 64-bit jiffies?

DISCUSSION george anzinger 7 participants 25 messages Oct 22, 2001 – May 13, 2002

Subsystems (9)
Arm (32-bit) Kbuild Scheduler s390 +5 more subsystems
lore
Share & tools
lore

george anzinger

author
#0 lore raw

I am working on POSIX timers where there is defined a CLOCK_MONOTONIC. The most reasonable implementation of this clock is that it is "uptime" or jiffies. The problem is that it is most definitely not MONOTONIC when it rolls back to 0 :( Thus the need for 64-bits.

As it turns out, the only code that needs to know about the high order bits is the code that increments jiffies and the POSIX timer code. Every thing else can continue to use the current definition with no problem.

The solution needs to account for the Endianess of the platform. Here are the possible solutions I have come up with:

1.) Define jiffies in the arch section of the code using asm. Looks like this for x86:

__asm__( ".global jiffies\n\t"

         ".global jiffiesll\n"
         ".global jiffiesh\n"
         "jiffiesll:\n"
         "jiffies: \n\t"

         ".long 0\n"
         "jiffiesh: \n\t"
         ".long 0");

The up side of this method is that none of the current using code needs to be aware of the change. We just remove "unsigned long volatile jiffies;" from timer.c.

The down side of this method is that all platforms must do something similar.

2.) Use a C structure that depends on ENDIAN defines:

 #if defined(__LITTLE_ENDIAN)
      union {
        long long jiffiesll;
        struct {
        int jiffiesl
        int jiffiesh
        } jiffieparts;
 }jiffiesu; 
 #elif defined(__BIG_ENDIAN)
     union {
        long long jiffies64;
        struct {
        int jiffiesh
        int jiffiesl
        } jiffieparts;

}jiffiesu;
#else
#error "I'm probably missing #include <asm/byteorder.h>" #endif
#define jiffies jiffiesu.jiffieparts.jiffiesl #define jiffiesll jiffiesu.jiffies64

The down side with this method is that jiffies can not be used as a local or structure
element, i.e. it is now a reserved name in the kernel.

3.) Define jiffies as 64 bit and use C casts to get to the low order part:

u64 jiffies_u64;

#define jiffies (unsigned long volatile)jiffies_u64

Here again the down side is that jiffies can not be used as a local or structure
element, i.e. it is now a reserved name in the kernel.

I am sure there are other ways to approach this and I would like to hear them.

Approach 1.) requires that all platforms be changed at the same time. Approaches 2.) and 3.) require that we find all occurrences of jiffies should not be "defined" to something else. The Ibm tick less patch found most of these, but I am sure there are more lurking in drivers.

Comments?

George

#1 lore raw
Quoted 4 lines · george anzinger

I am working on POSIX timers where there is defined a CLOCK_MONOTONIC. The most reasonable implementation of this clock is that it is "uptime" or jiffies. The problem is that it is most definitely not MONOTONIC when it rolls back to 0 :( Thus the need for 64-bits.

If you want to leave existing kernel code alone so it still uses 32 bit jiffies, just maintain a separate high order 32 bit field which is only used by the code that really needs it. On 32 bit machines, the jiffie code does

  old_jiffies = jiffies++;
  if (jiffies < old_jiffies)
  	++high_jiffies;

You will need a spin lock around that on 32 bit systems, but that is true for anything that tries to do 64 bit counter updates on a 32 bit system. None of your suggestions will work on ix86, it does not support atomic updates on 64 bit fields in hardware.

#2 lore raw
Quoted 13 lines · Keith Owens
Quoted 4 lines · george anzinger

I am working on POSIX timers where there is defined a CLOCK_MONOTONIC. The most reasonable implementation of this clock is that it is "uptime" or jiffies. The problem is that it is most definitely not MONOTONIC when it rolls back to 0 :( Thus the need for 64-bits.

If you want to leave existing kernel code alone so it still uses 32 bit jiffies, just maintain a separate high order 32 bit field which is only used by the code that really needs it. On 32 bit machines, the jiffie code does

Quoted 8 lines
  old_jiffies = jiffies++;
  if (jiffies < old_jiffies)
        ++high_jiffies;

You will need a spin lock around that on 32 bit systems, but that is true for anything that tries to do 64 bit counter updates on a 32 bit system. None of your suggestions will work on ix86, it does not support atomic updates on 64 bit fields in hardware.

cmpxchg8b does, but it's a bit indirect.

Signature · 1 line
						Brian Gerst
#3 lore raw
Quoted 6 lines · Brian Gerst
Quoted 3 lines · Keith Owens

You will need a spin lock around that on 32 bit systems, but that is true for anything that tries to do 64 bit counter updates on a 32 bit system.

cmpxchg8b does, but it's a bit indirect.

Not on 386, only on 486 and above. Besides, you want to avoid arch specific asm code.

author
#4 lore raw
In reply to Keith Owens
Quoted 13 lines · Keith Owens
Quoted 4 lines · george anzinger

I am working on POSIX timers where there is defined a CLOCK_MONOTONIC. The most reasonable implementation of this clock is that it is "uptime" or jiffies. The problem is that it is most definitely not MONOTONIC when it rolls back to 0 :( Thus the need for 64-bits.

If you want to leave existing kernel code alone so it still uses 32 bit jiffies, just maintain a separate high order 32 bit field which is only used by the code that really needs it. On 32 bit machines, the jiffie code does

Quoted 8 lines
  old_jiffies = jiffies++;
  if (jiffies < old_jiffies)
        ++high_jiffies;

You will need a spin lock around that on 32 bit systems, but that is true for anything that tries to do 64 bit counter updates on a 32 bit system. None of your suggestions will work on ix86, it does not support atomic updates on 64 bit fields in hardware.

As it turns out I already have a spinlock on the update jiffies code. The reason one would want to use a 64-bit integer is that the compiler does a MUCH better job of the ++, i.e. it just does an add carry. No if, no jmp. I suppose I need to lock the read also, but it is not done often and will hardly ever block.

I am beginning to think that defining a u64 and casting, i.e.:

#define jiffies (unsigned long volitial)jiffies_u64

is the way to go.

George

#5 lore raw
In reply to Keith Owens

In article <[email protected]>,

Quoted 6 lines · george anzinger

I am beginning to think that defining a u64 and casting, i.e.:

#define jiffies (unsigned long volitial)jiffies_u64

is the way to go.

..except for gcc being bad at even 64->32-bit casts like the above. It will usually still load the full 64-bit value, and then only use the low bits.

The efficient and sane way to do it is:

	/*
	 * The 64-bit value is not volatile - you MUST NOT read it
	 * without holding the spinlock
	 */
	u64 jiffies_64;

	/*
	 * Most people don't necessarily care about the full 64-bit
	 * value, so we can just get the "unstable" low bits without
	 * holding the lock. For historical reasons we also mark
	 * it volatile so that busy-waiting doesn't get optimized
	 * away in old drivers.
	 */
	#if defined(__LITTLE_ENDIAN) || (BITS_PER_LONG > 32)
	#define jiffies (((volatile unsigned long *)&jiffies_64)[0])
	#else
	#define jiffies (((volatile unsigned long *)&jiffies_64)[1])
	#endif

which looks ugly, but the ugliness is confined to that one place, and none of the users will ever have to care..

Linus

author
#6 lore raw
In reply to Keith Owens
Quoted 14 lines · Linus Torvalds

In article <[email protected]>,

Quoted 6 lines · george anzinger

I am beginning to think that defining a u64 and casting, i.e.:

#define jiffies (unsigned long volitial)jiffies_u64

is the way to go.

..except for gcc being bad at even 64->32-bit casts like the above. It will usually still load the full 64-bit value, and then only use the low bits.

Quoted 6 lines

The efficient and sane way to do it is:

/*
* The 64-bit value is not volatile - you MUST NOT read it
* without holding the spinlock
*/

Given that the spinlock would have to be spin_lock_irq (jiffies is updated in clock interrupt code), is there a way to avoid the lock? The following code does it for UP systems, given it is not rearranged. Is there something like this that will work for
SMP systems?

(assumeing the defines below):

	do {
		jiffies_f = jiffies;
		jiffies_64_f = jiffies_64;
	}
	while ( jiffies_f != jiffies);

If all things are in order, this will work on UP. Order could be enforced by using locked instructions for the jiffies access...

George

Quoted 19 lines
        u64 jiffies_64;

        /*
         * Most people don't necessarily care about the full 64-bit
         * value, so we can just get the "unstable" low bits without
         * holding the lock. For historical reasons we also mark
         * it volatile so that busy-waiting doesn't get optimized
         * away in old drivers.
         */
        #if defined(__LITTLE_ENDIAN) || (BITS_PER_LONG > 32)
        #define jiffies (((volatile unsigned long *)&jiffies_64)[0])
        #else
        #define jiffies (((volatile unsigned long *)&jiffies_64)[1])
        #endif

which looks ugly, but the ugliness is confined to that one place, and none of the users will ever have to care..

Linus

author
#7 lore raw

64-bit jiffies, a better solution

In reply to Keith Owens
Quoted 35 lines · Linus Torvalds

In article <[email protected]>,

Quoted 6 lines · george anzinger

I am beginning to think that defining a u64 and casting, i.e.:

#define jiffies (unsigned long volitial)jiffies_u64

is the way to go.

..except for gcc being bad at even 64->32-bit casts like the above. It will usually still load the full 64-bit value, and then only use the low bits.

The efficient and sane way to do it is:

        /*
         * The 64-bit value is not volatile - you MUST NOT read it
         * without holding the spinlock
         */
        u64 jiffies_64;

        /*
         * Most people don't necessarily care about the full 64-bit
         * value, so we can just get the "unstable" low bits without
         * holding the lock. For historical reasons we also mark
         * it volatile so that busy-waiting doesn't get optimized
         * away in old drivers.
         */
        #if defined(__LITTLE_ENDIAN) || (BITS_PER_LONG > 32)
        #define jiffies (((volatile unsigned long *)&jiffies_64)[0])
        #else
        #define jiffies (((volatile unsigned long *)&jiffies_64)[1])
        #endif
Quoted 4 lines

which looks ugly, but the ugliness is confined to that one place, and none of the users will ever have to care..

Linus

I tried the above and, aside from the numerous cases where "jiffies" appears
as a dummy variable or a struct/union member which had to be "fixed", I got
flack from some folks who thought that:

extern unsigned long jiffies;

should work. So here is a solution that does all the above and does NOT invade new name spaces:

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/Makefile linux/Makefile

Makefile +0 -0
@@ -262,6 +262,7 @@
 
 vmlinux: include/linux/version.h $(CONFIGURATION) init/main.o

init/version.o init/do_mounts.o linuxsubdirs
$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o init/do_mounts.o
\
+ kernel/jiffies_linker_file.lds \
--start-group \
$(CORE_FILES) \
$(LIBS) \
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/include/linux/sched.h linux/include/linux/sched.h

include/linux/sched.h +5 -0
@@ -459,6 +459,11 @@
 
 #include <asm/current.h>
 
+/*
+ * The 64-bit value is not volatile - you MUST NOT read it
+ * without holding read_lock_irq(&xtime_lock)
+ */
+extern u64 jiffies_64;
 extern unsigned long volatile jiffies;
 extern unsigned long itimer_ticks;
 extern unsigned long itimer_next;

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/kernel/jiffies_linker_file.lds linux/kernel/jiffies_linker_file.lds
--- linux-2.5.14-org/kernel/jiffies_linker_file.lds Wed Dec 31 16:00:00
1969
+++ linux/kernel/jiffies_linker_file.lds Fri May 10 14:10:28 2002
@@ -0,0 +1,14 @@
+/*
+ * This linker script defines jiffies to be either the same as
+ * jiffies_64 (for little endian or 64 bit machines) or
+ * jiffies_64+4 (for big endian machines)
+ *
+ * It is intended to satisfy external references to a 32 bit jiffies which
+ * is the low order 32-bits of a 64-bit jiffies.
+ *
+ * jiffies_at_jiffies_64 needs to be defined if this is a little endian
+ * or a 64-bit machine.
+ * Currently this is done in ..../kernel/timer.c
+ *
+ */
+jiffies =DEFINED(jiffies_at_jiffies_64) ? jiffies_64 : (jiffies_64 + 4);
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/kernel/ksyms.c linux/kernel/ksyms.c

kernel/ksyms.c +1 -0
@@ -471,6 +471,7 @@
 EXPORT_SYMBOL_GPL(set_cpus_allowed);
 #endif
 EXPORT_SYMBOL(jiffies);
+EXPORT_SYMBOL(jiffies_64);
 EXPORT_SYMBOL(xtime);
 EXPORT_SYMBOL(do_gettimeofday);
 EXPORT_SYMBOL(do_settimeofday);

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/kernel/timer.c linux/kernel/timer.c

kernel/timer.c +14 -1
@@ -67,7 +67,28 @@
 
 extern int do_setitimer(int, struct itimerval *, struct itimerval *);
 
-unsigned long volatile jiffies;
+/*
+ * The 64-bit value is not volatile - you MUST NOT read it
+ * without holding read_lock_irq(&xtime_lock)
+ */
+u64 jiffies_64;
+/*
+ * Most people don't necessarily care about the full 64-bit
+ * value, so we can just get the "unstable" low bits without
+ * holding the lock. For historical reasons we also mark
+ * it volatile so that busy-waiting doesn't get optimized
+ * away in old drivers.
+ *
+ * This definition depends on the linker defining the actual address of
+ * jiffies using the following (found in

.../kernel/jiffies_linker_file):
+ * jiffies = DEFINED(jiffies_at_jiffies_64) ? jiffies_64 :
jiffies_64+4;
+ */
+#if defined(__LITTLE_ENDIAN) || (BITS_PER_LONG > 32) +
+char jiffies_at_jiffies_64[0];
+#elif ! defined(__BIG_ENDIAN)
+#ERROR "Neither __LITTLE_ENDIAN nor __BIG_ENDIAN defined " +#endif

unsigned int * prof_buffer;
unsigned long prof_len;
@@ -664,7 +685,7 @@

void do_timer(struct pt_regs *regs)
{
- (*(unsigned long *)&jiffies)++;
+ (*(u64 *)&jiffies_64)++;
#ifndef CONFIG_SMP
/* SMP process accounting uses the local APIC timer */

----------------------------------------------------------------------

And for those who think doing a ++ on 64-bits is too much to do in an interrupt,
here is the before / after diff of the asm file for timer.c (messed up a bit so
patch doesn't get confused):

*-* /usr/src/linux-2.5.14-kb/kernel/timer.o Fri May 10 14:03:07 2002
*+* /usr/src/linux-2.5.14-kb/kernel/timer.s Fri May 10 14:02:03 2002
** -1371,7 +1371,8 **
.globl do_timer
.type do_timer,@function
do_timer:
- incl jiffies
+ addl $1,jiffies_64
+ adcl $0,jiffies_64+4
xorl %eax,%eax
#APP
lock ; btsl %eax,bh_task_vec+4
-----------------------------
This solution should work for all platforms and long sizes, does not depend on asm
and does not invade any new name spaces.

Signature · 4 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#8 lore raw

Re: 64-bit jiffies, a better solution

Quoted 3 lines · george anzinger

should work. So here is a solution that does all the above and does NOT invade new name spaces:

Ok, looks fine, but I'd really rather move the "jiffies" linker games into the per-architecture stuff, and get rid of the jiffies_at_jiffies_64 games.

It's just one line per architecture, after all.

Linus

author
#9 lore raw

Re: 64-bit jiffies, a better solution

Quoted 6 lines · Linus Torvalds
Quoted 3 lines · george anzinger

should work. So here is a solution that does all the above and does NOT invade new name spaces:

Quoted 7 lines

Ok, looks fine, but I'd really rather move the "jiffies" linker games into the per-architecture stuff, and get rid of the jiffies_at_jiffies_64 games.

It's just one line per architecture, after all.

Linus

If that were only true. The problem is that some architectures can be built with either endian. Mips, for example, seems to take the endian stuff in as an environment variable. The linker seems to know this stuff, but does not provide the "built in" to allow it to be used.

The info is available from the header files at compile time, but I could not find a clean way to export it to the Makefile, where we might choose which linker script to use. I suppose we could run the linker script thru cpp if all else fails. Any ideas?

Signature · 4 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#10 lore raw

Re: 64-bit jiffies, a better solution

Quoted 5 lines · george anzinger

If that were only true. The problem is that some architectures can be built with either endian. Mips, for example, seems to take the endian stuff in as an environment variable. The linker seems to know this stuff, but does not provide the "built in" to allow it to be used.

Ignore those for now, and let the architecture maintainer sort it out.

Quoted 1 line

From what I can tell, those architectures do things like generate the

linker script dynamically anyway, so..

Linus

author
#11 lore raw

Re: 64-bit jiffies, a better solution take 2

Quoted 8 lines · Linus Torvalds
Quoted 5 lines · george anzinger

If that were only true. The problem is that some architectures can be built with either endian. Mips, for example, seems to take the endian stuff in as an environment variable. The linker seems to know this stuff, but does not provide the "built in" to allow it to be used.

Quoted 5 lines

Ignore those for now, and let the architecture maintainer sort it out.

Quoted 1 line

From what I can tell, those architectures do things like generate the

linker script dynamically anyway, so..

Linus

Ok, here it is. The following arch are not covered:
Mips, Mips64 in 32-bit mode, parisc in __LP64__ mode.

In addition, x86_64 mentions jiffies in the existing script. This may be a problem.

arch/alpha/vmlinux.lds.in +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/alpha/vmlinux.lds.in linux/arch/alpha/vmlinux.lds.in
@@ -3,6 +3,7 @@
 OUTPUT_FORMAT("elf64-alpha")
 ENTRY(__start)
 PHDRS { kernel PT_LOAD ; }
+jiffies = jiffies_64;
 SECTIONS
 {
 #ifdef CONFIG_ALPHA_LEGACY_START_ADDRESS
arch/arm/vmlinux-armo.lds.in +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/arm/vmlinux-armo.lds.in linux/arch/arm/vmlinux-armo.lds.in
@@ -4,6 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
 	. = TEXTADDR;
arch/arm/vmlinux-armv.lds.in +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/arm/vmlinux-armv.lds.in linux/arch/arm/vmlinux-armv.lds.in
@@ -4,6 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
 	. = TEXTADDR;
arch/cris/cris.ld +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/cris/cris.ld linux/arch/cris/cris.ld
@@ -8,6 +8,7 @@
  * the kernel has booted. 
  */	
 
+jiffies = jiffies_64;
 SECTIONS
 {
 	. = @CONFIG_ETRAX_DRAM_VIRTUAL_BASE@;
arch/i386/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/i386/vmlinux.lds linux/arch/i386/vmlinux.lds
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
 OUTPUT_ARCH(i386)
 ENTRY(_start)
+jiffies = jiffies_64;
 SECTIONS
 {
   . = 0xC0000000 + 0x100000;
arch/ia64/vmlinux.lds.S +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/ia64/vmlinux.lds.S linux/arch/ia64/vmlinux.lds.S
@@ -7,6 +7,7 @@
 OUTPUT_FORMAT("elf64-ia64-little")
 OUTPUT_ARCH(ia64)
 ENTRY(phys_start)
+jiffies = jiffies_64; 
 SECTIONS
 {
   /* Sections to be discarded */
arch/m68k/vmlinux-sun3.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/m68k/vmlinux-sun3.lds linux/arch/m68k/vmlinux-sun3.lds
@@ -2,6 +2,7 @@
 OUTPUT_FORMAT("elf32-m68k", "elf32-m68k", "elf32-m68k")
 OUTPUT_ARCH(m68k)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0xE004000;
arch/m68k/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/m68k/vmlinux.lds linux/arch/m68k/vmlinux.lds
@@ -2,6 +2,7 @@
 OUTPUT_FORMAT("elf32-m68k", "elf32-m68k", "elf32-m68k")
 OUTPUT_ARCH(m68k)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0x1000;
arch/mips64/ld.script.elf64 +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/mips64/ld.script.elf64 linux/arch/mips64/ld.script.elf64
@@ -1,5 +1,6 @@
 OUTPUT_ARCH(mips)
 ENTRY(kernel_entry)
+jiffies = jiffies_64;
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */
arch/parisc/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/parisc/vmlinux.lds linux/arch/parisc/vmlinux.lds
@@ -2,6 +2,7 @@
 OUTPUT_FORMAT("elf32-hppa")
 OUTPUT_ARCH(hppa)
 ENTRY(_stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
arch/ppc/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/ppc/vmlinux.lds linux/arch/ppc/vmlinux.lds
@@ -2,6 +2,7 @@
 SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/local/powerpc-any-elf/lib);
 /* Do we need any of these for elf?
    __DYNAMIC = 0;    */
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */
arch/ppc64/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/ppc64/vmlinux.lds linux/arch/ppc64/vmlinux.lds
@@ -2,6 +2,7 @@
 SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/local/powerpc-any-elf/lib);
 /* Do we need any of these for elf?
    __DYNAMIC = 0;    */
+jiffies = jiffies_64;
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */
arch/s390/vmlinux-shared.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/s390/vmlinux-shared.lds linux/arch/s390/vmlinux-shared.lds
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf32-s390", "elf32-s390", "elf32-s390")
 OUTPUT_ARCH(s390)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0x00000000;
arch/s390/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/s390/vmlinux.lds linux/arch/s390/vmlinux.lds
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf32-s390", "elf32-s390", "elf32-s390")
 OUTPUT_ARCH(s390)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0x00000000;
arch/s390x/vmlinux-shared.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/s390x/vmlinux-shared.lds linux/arch/s390x/vmlinux-shared.lds
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf64-s390", "elf64-s390", "elf64-s390")
 OUTPUT_ARCH(s390)
 ENTRY(_start)
+jiffies = jiffies_64;
 SECTIONS
 {
   . = 0x00000000;
arch/s390x/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/s390x/vmlinux.lds linux/arch/s390x/vmlinux.lds
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf64-s390", "elf64-s390", "elf64-s390")
 OUTPUT_ARCH(s390)
 ENTRY(_start)
+jiffies = jiffies_64;
 SECTIONS
 {
   . = 0x00000000;
arch/sh/vmlinux.lds.S +2 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/sh/vmlinux.lds.S linux/arch/sh/vmlinux.lds.S
@@ -5,8 +5,10 @@
 #include <linux/config.h>
 #ifdef CONFIG_CPU_LITTLE_ENDIAN
 OUTPUT_FORMAT("elf32-sh-linux", "elf32-sh-linux", "elf32-sh-linux")
+jiffies = jiffies_64;        
 #else
 OUTPUT_FORMAT("elf32-shbig-linux", "elf32-shbig-linux", "elf32-shbig-linux")
+jiffies = jiffies_64 + 4;
 #endif
 OUTPUT_ARCH(sh)
 ENTRY(_start)
arch/sparc/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/sparc/vmlinux.lds linux/arch/sparc/vmlinux.lds
@@ -2,6 +2,7 @@
 OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc")
 OUTPUT_ARCH(sparc)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0x10000 + SIZEOF_HEADERS;
arch/sparc64/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/sparc64/vmlinux.lds linux/arch/sparc64/vmlinux.lds
@@ -3,6 +3,7 @@
 OUTPUT_ARCH(sparc:v9a)
 ENTRY(_start)
 
+jiffies = jiffies_64;
 SECTIONS
 {
   swapper_pmd_dir = 0x0000000000402000;
arch/x86_64/vmlinux.lds +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/x86_64/vmlinux.lds linux/arch/x86_64/vmlinux.lds
@@ -3,6 +3,7 @@
  */
 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
 OUTPUT_ARCH(i386:x86-64)
+jiffies = jiffies_64;
 ENTRY(_start)
 SECTIONS
 {
include/linux/sched.h +5 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/include/linux/sched.h linux/include/linux/sched.h
@@ -459,6 +459,11 @@
 
 #include <asm/current.h>
 
+/*
+ * The 64-bit value is not volatile - you MUST NOT read it
+ * without holding read_lock_irq(&xtime_lock)
+ */
+extern u64 jiffies_64;
 extern unsigned long volatile jiffies;
 extern unsigned long itimer_ticks;
 extern unsigned long itimer_next;
kernel/ksyms.c +1 -0
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/kernel/ksyms.c linux/kernel/ksyms.c
@@ -471,6 +471,7 @@
 EXPORT_SYMBOL_GPL(set_cpus_allowed);
 #endif
 EXPORT_SYMBOL(jiffies);
+EXPORT_SYMBOL(jiffies_64);
 EXPORT_SYMBOL(xtime);
 EXPORT_SYMBOL(do_gettimeofday);
 EXPORT_SYMBOL(do_settimeofday);
kernel/timer.c +7 -2
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/kernel/timer.c linux/kernel/timer.c
@@ -67,7 +67,12 @@
 
 extern int do_setitimer(int, struct itimerval *, struct itimerval *);
 
-unsigned long volatile jiffies;
+/*
+ * The 64-bit value is not volatile - you MUST NOT read it
+ * without holding read_lock_irq(&xtime_lock).
+ * jiffies is defined in the linker script...
+ */
+u64 jiffies_64;
 
 unsigned int * prof_buffer;
 unsigned long prof_len;

@@ -664,7 +669,7 @@
 
 void do_timer(struct pt_regs *regs)
 {
-	(*(unsigned long *)&jiffies)++;
+	(*(u64 *)&jiffies_64)++;
 #ifndef CONFIG_SMP
 	/* SMP process accounting uses the local APIC timer */
Signature · 4 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#12 lore raw

Re: 64-bit jiffies, a better solution take 2

In reply to Linus Torvalds
Quoted 15 lines · george anzinger

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/arm/vmlinux-armo.lds.in linux/arch/arm/vmlinux-armo.lds.in

arch/arm/vmlinux-armo.lds.in +1 -0
@@ -4,6 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
 	. = TEXTADDR;

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/arm/vmlinux-armv.lds.in linux/arch/arm/vmlinux-armv.lds.in

arch/arm/vmlinux-armv.lds.in line 10

Quoted 7 lines
arch/arm/vmlinux-armv.lds.in +1 -0
@@ -4,6 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
 	. = TEXTADDR;

Eurgh. This seems to be a popular misconception. What makes you think ARM is big endian, or was it just a guess?

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
author
#13 lore raw

Re: 64-bit jiffies, a better solution take 2

In reply to Linus Torvalds
Quoted 29 lines · Russell King
Quoted 15 lines · george anzinger

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/arm/vmlinux-armo.lds.in linux/arch/arm/vmlinux-armo.lds.in

arch/arm/vmlinux-armo.lds.in Fri May 10 17:07:31 2002 renamed from arch/arm/vmlinux-armo.lds.in Tue May 7 15:59:35 2002 +1 -0
@@ -4,6 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
      . = TEXTADDR;

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/arm/vmlinux-armv.lds.in linux/arch/arm/vmlinux-armv.lds.in

arch/arm/vmlinux-armv.lds.in Fri May 10 17:07:34 2002 line 10

Quoted 7 lines
arch/arm/vmlinux-armv.lds.in Fri May 10 17:07:34 2002 renamed from arch/arm/vmlinux-armv.lds.in Tue May 7 15:59:35 2002 +1 -0
@@ -4,6 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
      . = TEXTADDR;

Eurgh. This seems to be a popular misconception. What makes you think ARM is big endian, or was it just a guess?

Quoted 1 line

From byteorder.h:

#ifdef __ARMEB__
#include <linux/byteorder/big_endian.h>
#else
#include <linux/byteorder/little_endian.h>
#endif

So, yes, given no hints on who or what configures __ARMEB__. Is it always little endian?

Signature · 4 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#14 lore raw

Re: 64-bit jiffies, a better solution take 2

In reply to Linus Torvalds
Quoted 8 lines · george anzinger

#ifdef __ARMEB__
#include <linux/byteorder/big_endian.h>
#else
#include <linux/byteorder/little_endian.h>
#endif

So, yes, given no hints on who or what configures __ARMEB__. Is it always little endian?

Most sane people use ARM in little endian mode. However, there are a few insane people (mostly from the Telecoms sector) who like to put the chips into the (broken) big endian mode.

We don't fully support big endian in the -rmk kernel (and therefore Linus' kernel) yet.

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#15 lore raw

Re: 64-bit jiffies, a better solution take 2

In reply to Linus Torvalds
Quoted 32 lines · george anzinger
Quoted 29 lines · Russell King
Quoted 15 lines · george anzinger

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/arm/vmlinux-armo.lds.in linux/arch/arm/vmlinux-armo.lds.in

arch/arm/vmlinux-armo.lds.in Fri May 10 17:07:31 2002 renamed from arch/arm/vmlinux-armo.lds.in Tue May 7 15:59:35 2002 +1 -0
@@ -4,6 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
      . = TEXTADDR;

diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/arm/vmlinux-armv.lds.in linux/arch/arm/vmlinux-armv.lds.in

arch/arm/vmlinux-armv.lds.in Fri May 10 17:07:34 2002 line 10

Quoted 7 lines
arch/arm/vmlinux-armv.lds.in Fri May 10 17:07:34 2002 renamed from arch/arm/vmlinux-armv.lds.in Tue May 7 15:59:35 2002 +1 -0
@@ -4,6 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
      . = TEXTADDR;

Eurgh. This seems to be a popular misconception. What makes you think ARM is big endian, or was it just a guess?

Quoted 1 line

From byteorder.h:

Quoted 7 lines

#ifdef __ARMEB__
#include <linux/byteorder/big_endian.h>
#else
#include <linux/byteorder/little_endian.h>
#endif

So, yes, given no hints on who or what configures __ARMEB__. Is it always little endian?

The compiler does; that's true of most __*__ macros used in the kernel. If you build a big-endian compiler, you'll get __ARMEB__.

Signature · 2 lines
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer
author
#16 lore raw

Re: 64-bit jiffies, a better solution take 2

In reply to Linus Torvalds
Quoted 11 lines · Russell King
Quoted 8 lines · george anzinger

#ifdef __ARMEB__
#include <linux/byteorder/big_endian.h>
#else
#include <linux/byteorder/little_endian.h>
#endif

So, yes, given no hints on who or what configures __ARMEB__. Is it always little endian?

Quoted 6 lines

Most sane people use ARM in little endian mode. However, there are a few insane people (mostly from the Telecoms sector) who like to put the chips into the (broken) big endian mode.

We don't fully support big endian in the -rmk kernel (and therefore Linus' kernel) yet.

So, what to do? For ARM and MIPS we could go back to solution 1:

+#if defined(__LITTLE_ENDIAN) || (BITS_PER_LONG > 32) +char jiffies_at_jiffies_64[0];
+#elif ! defined(__BIG_ENDIAN)
+#ERROR "Neither __LITTLE_ENDIAN nor __BIG_ENDIAN defined " +#endif

With this in the ld script file:
jiffies = DEFINED(jiffies_at_jiffies_64) ? jiffies_64 : jiffies_64+4;

This would work no matter what endian was used. If this is to be the ARM/ MIPS answer, what file should the #if... go in?

Signature · 4 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#17 lore raw

Re: 64-bit jiffies, a better solution take 2

Quoted 2 lines · george anzinger

So, what to do? For ARM and MIPS we could go back to solution 1:

Why not just put that knowledge in the ARM/MIPS architecture makefile?

ARM already has multiple linker scripts, and it already selects on them based on CONFIG options, so I'd much rather just do that straightforward kind of thing than play any clever games.

MIPS runs some sed script on it and that could be expanded to do this, and all the same arguments apply.

Linus

#18 lore raw

Re: 64-bit jiffies, a better solution take 2

In reply to george anzinger
Quoted 9 lines · Linus Torvalds
Quoted 2 lines · george anzinger

So, what to do? For ARM and MIPS we could go back to solution 1:

Why not just put that knowledge in the ARM/MIPS architecture makefile?

ARM already has multiple linker scripts, and it already selects on them based on CONFIG options, so I'd much rather just do that straightforward kind of thing than play any clever games.

So would I - there will be a config option, so we can just use sed on the relevant linker script to do the right thing.

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#19 lore raw

Re: 64-bit jiffies, a better solution take 2

Quoted 5 lines · Russell King
Quoted 4 lines · Linus Torvalds
Quoted 2 lines · george anzinger

So, what to do? For ARM and MIPS we could go back to solution 1:

Quoted 8 lines
Quoted 5 lines

Why not just put that knowledge in the ARM/MIPS architecture makefile?

ARM already has multiple linker scripts, and it already selects on them based on CONFIG options, so I'd much rather just do that straightforward kind of thing than play any clever games.

So would I - there will be a config option, so we can just use sed on the relevant linker script to do the right thing.

Any reason that you are using sed and not cpp like the other architectures?

The use and name of linker scripts varies across architectures, some use cpp, some use sed, some do not pre-process at all. This makes it awkward for repositories and dont-diff lists, they need special rules for every architecture. In kbuild 2.5 I am trying to standardize on arch/$(ARCH)/vmlinux.lds.S which is always pre-processed by cpp to vmlinux.lds.i which is used to link vmlinux.

Using .S -> .i has three benefits. The file name and the code for converting the file is standardized. Dont-diff lists exclude *.[oais] files, no need for special cases for each architecture. kbuild 2.5 tracks the command, timestamp and dependencies for all .S -> .i conversions so the ld script will become a properly controlled file, being rebuilt when necessary and only when necessary.

For architectures that need to choose between multiple ld scripts. In my tree I have made the ld script name a variable (arch_ld_script) that may be set in arch/$(ARCH)/Makefile.defs.config. If the variable is not set, it defaults to /arch/$(ARCH)/vmlinux.lds.i.

#20 lore raw

Re: 64-bit jiffies, a better solution take 2

In reply to Russell King
Quoted 2 lines · Keith Owens

Any reason that you are using sed and not cpp like the other architectures?

Only historical and a hatred of cpp's "# line file" stuff, and the fact that ARM needs to use sed elsewhere in the build to get around broken GCC %c0 stuff.

I think we could actually get rid of the preprocessing of the linker files - see ld's defsym argument.

Quoted 6 lines

The use and name of linker scripts varies across architectures, some use cpp, some use sed, some do not pre-process at all. This makes it awkward for repositories and dont-diff lists, they need special rules for every architecture. In kbuild 2.5 I am trying to standardize on arch/$(ARCH)/vmlinux.lds.S which is always pre-processed by cpp to vmlinux.lds.i which is used to link vmlinux.

Eww, so I can't use "find . -name '*.[cS]'" to find all the C source and assembly source with kbuild 2.5 because we've got pollution of the .S extension?

Quoted 3 lines

Using .S -> .i has three benefits. The file name and the code for converting the file is standardized. Dont-diff lists exclude *.[oais] files, no need for special cases for each architecture.

I'm not a fan of dont-diff stuff myself - I'd rather ensure a clean source tree and then diff rather than diffing a dirty built tree. dont-diff stuff needs to be maintained and extended as stuff changes in the kernel tree, and lets face it, no amount of extension pollution will prevent it from being updated over time.

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#21 lore raw

Re: 64-bit jiffies, a better solution take 2

Quoted 9 lines · Russell King
Quoted 2 lines · Keith Owens

Any reason that you are using sed and not cpp like the other architectures?

Only historical and a hatred of cpp's "# line file" stuff, and the fact that ARM needs to use sed elsewhere in the build to get around broken GCC %c0 stuff.

From arch/$(ARCH)/Makefile.in

  extra_aflags(vmlinux.lds.i -U$(ARCH) -C -P)

-P suppresses the '# line file' stuff.

Quoted 2 lines

I think we could actually get rid of the preprocessing of the linker files - see ld's defsym argument.

Some architectures need #ifdef in their script, they control more than just values (sh, ia64). I like standard code, so use cpp for everything.

Quoted 7 lines
Quoted 3 lines

In kbuild 2.5 I am trying to standardize on arch/$(ARCH)/vmlinux.lds.S which is always pre-processed by cpp to vmlinux.lds.i which is used to link vmlinux.

Eww, so I can't use "find . -name '*.[cS]'" to find all the C source and assembly source with kbuild 2.5 because we've got pollution of the .S extension?

Don't blame kbuild 2.5 for that.

arch/ia64/vmlinux.lds.S
arch/mips64/ld.script.elf32.S
arch/sh/vmlinux.lds.S

I am just following the most common existing convention, trying to minimize changes to existing files for kbuild 2.5.

Quoted 2 lines

I'm not a fan of dont-diff stuff myself - I'd rather ensure a clean source tree and then diff rather than diffing a dirty built tree.

Then you must like separate source and object trees for kbuild 2.5 :)

Quoted 3 lines

dont-diff stuff needs to be maintained and extended as stuff changes in the kernel tree, and lets face it, no amount of extension pollution will prevent it from being updated over time.

True, but we can try to minimize the special cases.

author
#22 lore raw

Re: 64-bit jiffies, a better solution take 2

Quoted 10 lines · Keith Owens
Quoted 7 lines · Russell King
Quoted 2 lines · Keith Owens

Any reason that you are using sed and not cpp like the other architectures?

Only historical and a hatred of cpp's "# line file" stuff, and the fact that ARM needs to use sed elsewhere in the build to get around broken GCC %c0 stuff.

The interesting thing is that, in this case, cpp HAS THE INFO to do the job, while it would be a bit of a hassel to round it up for sed. I.e. the endian macro is defined in the cpp build, not in macros naturally available to make or sed. At the same time any thing make knows can easily be push into cpp via a command line macro.

~snip

Signature · 4 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
author
#23 lore raw

Re: 64-bit jiffies, a better solution take 2 (Fix ARM)

In reply to george anzinger
Quoted 12 lines · Russell King
Quoted 9 lines · Linus Torvalds
Quoted 2 lines · george anzinger

So, what to do? For ARM and MIPS we could go back to solution 1:

Why not just put that knowledge in the ARM/MIPS architecture makefile?

ARM already has multiple linker scripts, and it already selects on them based on CONFIG options, so I'd much rather just do that straightforward kind of thing than play any clever games.

Quoted 6 lines

So would I - there will be a config option, so we can just use sed on the relevant linker script to do the right thing.

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

Ok, here is the change to move ARM to little endian (apply after take 2):

arch/arm/vmlinux-armo.lds.in +1 -1
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.15-kb2/arch/arm/vmlinux-armo.lds.in linux/arch/arm/vmlinux-armo.lds.in
@@ -4,7 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
-jiffies = jiffies_64 + 4;
+jiffies = jiffies_64;
 SECTIONS
 {
 	. = TEXTADDR;
arch/arm/vmlinux-armv.lds.in +1 -1
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.15-kb2/arch/arm/vmlinux-armv.lds.in linux/arch/arm/vmlinux-armv.lds.in
@@ -4,7 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
-jiffies = jiffies_64 + 4;
+jiffies = jiffies_64;
 SECTIONS
 {
 	. = TEXTADDR;
Signature · 4 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#24 lore raw

Re: 64-bit jiffies, a better solution

In reply to george anzinger
Quoted 4 lines · george anzinger

If that were only true. The problem is that some architectures can be built with either endian. Mips, for example, seems to take the endian stuff in as an environment variable. The linker seems to know this stuff, but does not provide the "built in" to allow it to be used.

Huh? You can use CONFIG_CPU_LITTLE_ENDIAN. Gcc and the linker for
MIPS/Linux typically support both endiannesses (with a default selected at their build time) and it's the configuration variable that selects either of them.

Quoted 4 lines

The info is available from the header files at compile time, but I could not find a clean way to export it to the Makefile, where we might choose which linker script to use. I suppose we could run the linker script thru cpp if all else fails. Any ideas?

CONFIG_CPU_LITTLE_ENDIAN is available to Makefiles. There used to be
separate linker scripts for different endiannesses for MIPS once.

Signature · 3 lines
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email protected], PGP key available        +