How should we do a 64-bit jiffies?

How should we do a 64-bit jiffies?

[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.

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

Re: How should we do a 64-bit jiffies?

[Keith Owens]

On Mon, 22 Oct 2001 08:12:24 -0700, 
george anzinger <george@mvista.com> wrote:
>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.

Re: How should we do a 64-bit jiffies?

[Brian Gerst]

Keith Owens wrote:
> 
> On Mon, 22 Oct 2001 08:12:24 -0700,
> george anzinger <george@mvista.com> wrote:
> >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.

cmpxchg8b does, but it's a bit indirect.

-- 

						Brian Gerst

Re: How should we do a 64-bit jiffies?

[Keith Owens]

On Tue, 23 Oct 2001 02:05:54 -0400, 
Brian Gerst <bgerst@didntduck.org> wrote:
>Keith Owens wrote:
>> 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.

Re: How should we do a 64-bit jiffies?

[george anzinger]

Keith Owens wrote:
> 
> On Mon, 22 Oct 2001 08:12:24 -0700,
> george anzinger <george@mvista.com> wrote:
> >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.

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

Re: How should we do a 64-bit jiffies?

[Linus Torvalds]

In article <3BD52454.218387D9@mvista.com>,
george anzinger  <george@mvista.com> wrote:
>
>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

Re: How should we do a 64-bit jiffies?

[george anzinger]

Linus Torvalds wrote:
> 
> In article <3BD52454.218387D9@mvista.com>,
> george anzinger  <george@mvista.com> wrote:
> >
> >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
>          */
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


>         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

64-bit jiffies, a better solution

[george anzinger]

Linus Torvalds wrote:
> 
> In article <3BD52454.218387D9@mvista.com>,
> george anzinger  <george@mvista.com> wrote:
> >
> >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

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
--- linux-2.5.14-org/Makefile	Tue May  7 16:25:52 2002
+++ linux/Makefile	Thu May  9 18:18:53 2002
@@ -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
--- linux-2.5.14-org/include/linux/sched.h	Tue May  7 16:57:58 2002
+++ linux/include/linux/sched.h	Thu May  9 17:26:25 2002
@@ -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
--- linux-2.5.14-org/kernel/ksyms.c	Tue May  7 16:25:15 2002
+++ linux/kernel/ksyms.c	Thu May  9 17:21:43 2002
@@ -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
--- linux-2.5.14-org/kernel/timer.c	Tue May  7 16:15:52 2002
+++ linux/kernel/timer.c	Fri May 10 14:08:37 2002
@@ -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.

-- 
George Anzinger   george@mvista.com
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

Re: 64-bit jiffies, a better solution

[Linus Torvalds]

On Fri, 10 May 2002, george anzinger wrote:
> 
> 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

Re: 64-bit jiffies, a better solution

[george anzinger]

Linus Torvalds wrote:
> 
> On Fri, 10 May 2002, george anzinger wrote:
> >
> > 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
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?
-- 
George Anzinger   george@mvista.com
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

Re: 64-bit jiffies, a better solution

[Linus Torvalds]

On Fri, 10 May 2002, george anzinger wrote:
>
> 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. 
>From what I can tell, those architectures do things like generate the 
linker script dynamically anyway, so..

		Linus

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

[george anzinger]

Linus Torvalds wrote:
> 
> On Fri, 10 May 2002, george anzinger wrote:
> >
> > 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.
> >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.


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
--- linux-2.5.14-org/arch/alpha/vmlinux.lds.in	Tue May  7 16:08:34 2002
+++ linux/arch/alpha/vmlinux.lds.in	Fri May 10 16:56:03 2002
@@ -3,6 +3,7 @@
 OUTPUT_FORMAT("elf64-alpha")
 ENTRY(__start)
 PHDRS { kernel PT_LOAD ; }
+jiffies = jiffies_64;
 SECTIONS
 {
 #ifdef CONFIG_ALPHA_LEGACY_START_ADDRESS
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
--- linux-2.5.14-org/arch/arm/vmlinux-armo.lds.in	Tue May  7 15:59:35 2002
+++ linux/arch/arm/vmlinux-armo.lds.in	Fri May 10 17:07:31 2002
@@ -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
--- linux-2.5.14-org/arch/arm/vmlinux-armv.lds.in	Tue May  7 15:59:35 2002
+++ linux/arch/arm/vmlinux-armv.lds.in	Fri May 10 17:07:34 2002
@@ -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/cris/cris.ld linux/arch/cris/cris.ld
--- linux-2.5.14-org/arch/cris/cris.ld	Tue May  7 16:06:14 2002
+++ linux/arch/cris/cris.ld	Fri May 10 17:08:39 2002
@@ -8,6 +8,7 @@
  * the kernel has booted. 
  */	
 
+jiffies = jiffies_64;
 SECTIONS
 {
 	. = @CONFIG_ETRAX_DRAM_VIRTUAL_BASE@;
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/i386/vmlinux.lds linux/arch/i386/vmlinux.lds
--- linux-2.5.14-org/arch/i386/vmlinux.lds	Tue May  7 16:13:12 2002
+++ linux/arch/i386/vmlinux.lds	Fri May 10 16:53:50 2002
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
 OUTPUT_ARCH(i386)
 ENTRY(_start)
+jiffies = jiffies_64;
 SECTIONS
 {
   . = 0xC0000000 + 0x100000;
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
--- linux-2.5.14-org/arch/ia64/vmlinux.lds.S	Tue May  7 16:20:04 2002
+++ linux/arch/ia64/vmlinux.lds.S	Fri May 10 17:10:14 2002
@@ -7,6 +7,7 @@
 OUTPUT_FORMAT("elf64-ia64-little")
 OUTPUT_ARCH(ia64)
 ENTRY(phys_start)
+jiffies = jiffies_64; 
 SECTIONS
 {
   /* Sections to be discarded */
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
--- linux-2.5.14-org/arch/m68k/vmlinux-sun3.lds	Tue May  7 16:06:15 2002
+++ linux/arch/m68k/vmlinux-sun3.lds	Fri May 10 17:12:23 2002
@@ -2,6 +2,7 @@
 OUTPUT_FORMAT("elf32-m68k", "elf32-m68k", "elf32-m68k")
 OUTPUT_ARCH(m68k)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0xE004000;
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/m68k/vmlinux.lds linux/arch/m68k/vmlinux.lds
--- linux-2.5.14-org/arch/m68k/vmlinux.lds	Tue May  7 16:06:15 2002
+++ linux/arch/m68k/vmlinux.lds	Fri May 10 17:11:58 2002
@@ -2,6 +2,7 @@
 OUTPUT_FORMAT("elf32-m68k", "elf32-m68k", "elf32-m68k")
 OUTPUT_ARCH(m68k)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0x1000;
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
--- linux-2.5.14-org/arch/mips64/ld.script.elf64	Tue May  7 15:59:38 2002
+++ linux/arch/mips64/ld.script.elf64	Fri May 10 17:30:11 2002
@@ -1,5 +1,6 @@
 OUTPUT_ARCH(mips)
 ENTRY(kernel_entry)
+jiffies = jiffies_64;
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/parisc/vmlinux.lds linux/arch/parisc/vmlinux.lds
--- linux-2.5.14-org/arch/parisc/vmlinux.lds	Tue May  7 15:59:38 2002
+++ linux/arch/parisc/vmlinux.lds	Fri May 10 17:17:14 2002
@@ -2,6 +2,7 @@
 OUTPUT_FORMAT("elf32-hppa")
 OUTPUT_ARCH(hppa)
 ENTRY(_stext)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
 
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/ppc/vmlinux.lds linux/arch/ppc/vmlinux.lds
--- linux-2.5.14-org/arch/ppc/vmlinux.lds	Tue May  7 16:13:12 2002
+++ linux/arch/ppc/vmlinux.lds	Fri May 10 17:18:01 2002
@@ -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: */
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/ppc64/vmlinux.lds linux/arch/ppc64/vmlinux.lds
--- linux-2.5.14-org/arch/ppc64/vmlinux.lds	Tue May  7 16:18:05 2002
+++ linux/arch/ppc64/vmlinux.lds	Fri May 10 17:19:02 2002
@@ -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: */
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
--- linux-2.5.14-org/arch/s390/vmlinux-shared.lds	Tue May  7 16:06:16 2002
+++ linux/arch/s390/vmlinux-shared.lds	Fri May 10 17:19:59 2002
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf32-s390", "elf32-s390", "elf32-s390")
 OUTPUT_ARCH(s390)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0x00000000;
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/s390/vmlinux.lds linux/arch/s390/vmlinux.lds
--- linux-2.5.14-org/arch/s390/vmlinux.lds	Tue May  7 16:06:16 2002
+++ linux/arch/s390/vmlinux.lds	Fri May 10 17:20:38 2002
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf32-s390", "elf32-s390", "elf32-s390")
 OUTPUT_ARCH(s390)
 ENTRY(_start)
+jiffies = jiffies_64 + 4;
 SECTIONS
 {
   . = 0x00000000;
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
--- linux-2.5.14-org/arch/s390x/vmlinux-shared.lds	Tue May  7 16:06:16 2002
+++ linux/arch/s390x/vmlinux-shared.lds	Fri May 10 17:21:53 2002
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf64-s390", "elf64-s390", "elf64-s390")
 OUTPUT_ARCH(s390)
 ENTRY(_start)
+jiffies = jiffies_64;
 SECTIONS
 {
   . = 0x00000000;
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/s390x/vmlinux.lds linux/arch/s390x/vmlinux.lds
--- linux-2.5.14-org/arch/s390x/vmlinux.lds	Tue May  7 16:06:16 2002
+++ linux/arch/s390x/vmlinux.lds	Fri May 10 17:22:29 2002
@@ -4,6 +4,7 @@
 OUTPUT_FORMAT("elf64-s390", "elf64-s390", "elf64-s390")
 OUTPUT_ARCH(s390)
 ENTRY(_start)
+jiffies = jiffies_64;
 SECTIONS
 {
   . = 0x00000000;
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
--- linux-2.5.14-org/arch/sh/vmlinux.lds.S	Tue May  7 16:06:16 2002
+++ linux/arch/sh/vmlinux.lds.S	Fri May 10 17:24:46 2002
@@ -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)
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/sparc/vmlinux.lds linux/arch/sparc/vmlinux.lds
--- linux-2.5.14-org/arch/sparc/vmlinux.lds	Tue May  7 16:15:28 2002
+++ linux/arch/sparc/vmlinux.lds	Fri May 10 17:25:31 2002
@@ -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;
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/arch/sparc64/vmlinux.lds linux/arch/sparc64/vmlinux.lds
--- linux-2.5.14-org/arch/sparc64/vmlinux.lds	Tue May  7 16:15:30 2002
+++ linux/arch/sparc64/vmlinux.lds	Fri May 10 17:26:14 2002
@@ -3,6 +3,7 @@
 OUTPUT_ARCH(sparc:v9a)
 ENTRY(_start)
 
+jiffies = jiffies_64;
 SECTIONS
 {
   swapper_pmd_dir = 0x0000000000402000;
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
--- linux-2.5.14-org/arch/x86_64/vmlinux.lds	Tue May  7 16:20:04 2002
+++ linux/arch/x86_64/vmlinux.lds	Fri May 10 17:26:45 2002
@@ -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
 {
diff -urP -I \$Id:.*Exp \$ -X /usr/src/patch.exclude linux-2.5.14-org/include/linux/sched.h linux/include/linux/sched.h
--- linux-2.5.14-org/include/linux/sched.h	Tue May  7 16:57:58 2002
+++ linux/include/linux/sched.h	Thu May  9 17:26:25 2002
@@ -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/ksyms.c linux/kernel/ksyms.c
--- linux-2.5.14-org/kernel/ksyms.c	Tue May  7 16:25:15 2002
+++ linux/kernel/ksyms.c	Thu May  9 17:21:43 2002
@@ -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
--- linux-2.5.14-org/kernel/timer.c	Tue May  7 16:15:52 2002
+++ linux/kernel/timer.c	Fri May 10 16:35:39 2002
@@ -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 */
 

-- 
George Anzinger   george@mvista.com
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

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

[Russell King]

On Fri, May 10, 2002 at 05:42:46PM -0700, george anzinger wrote:
> 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
> --- linux-2.5.14-org/arch/arm/vmlinux-armo.lds.in	Tue May  7 15:59:35 2002
> +++ linux/arch/arm/vmlinux-armo.lds.in	Fri May 10 17:07:31 2002
> @@ -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
> --- linux-2.5.14-org/arch/arm/vmlinux-armv.lds.in	Tue May  7 15:59:35 2002
> +++ linux/arch/arm/vmlinux-armv.lds.in	Fri May 10 17:07:34 2002
> @@ -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?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

[george anzinger]

Russell King wrote:
> 
> On Fri, May 10, 2002 at 05:42:46PM -0700, george anzinger wrote:
> > 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
> > --- linux-2.5.14-org/arch/arm/vmlinux-armo.lds.in     Tue May  7 15:59:35 2002
> > +++ linux/arch/arm/vmlinux-armo.lds.in        Fri May 10 17:07:31 2002
> > @@ -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
> > --- linux-2.5.14-org/arch/arm/vmlinux-armv.lds.in     Tue May  7 15:59:35 2002
> > +++ linux/arch/arm/vmlinux-armv.lds.in        Fri May 10 17:07:34 2002
> > @@ -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?
> 

>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?
-- 
George Anzinger   george@mvista.com
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

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

[Russell King]

On Sat, May 11, 2002 at 08:01:34AM -0700, george anzinger wrote:
> #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.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

[george anzinger]

Russell King wrote:
> 
> On Sat, May 11, 2002 at 08:01:34AM -0700, george anzinger wrote:
> > #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.

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?
-- 
George Anzinger   george@mvista.com
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

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

[Linus Torvalds]

On Sat, 11 May 2002, george anzinger wrote:
>
> 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

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

[Russell King]

On Sat, May 11, 2002 at 10:37:39AM -0700, Linus Torvalds wrote:
> On Sat, 11 May 2002, george anzinger wrote:
> >
> > 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.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

[Keith Owens]

On Sat, 11 May 2002 19:11:18 +0100, 
Russell King <rmk@arm.linux.org.uk> wrote:
>On Sat, May 11, 2002 at 10:37:39AM -0700, Linus Torvalds wrote:
>> On Sat, 11 May 2002, george anzinger wrote:
>> >
>> > 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.

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.

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

[Russell King]

On Sun, May 12, 2002 at 09:38:48AM +1000, Keith Owens wrote:
> 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.

> 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?

> 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.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

[Keith Owens]

On Sun, 12 May 2002 01:01:21 +0100, 
Russell King <rmk@arm.linux.org.uk> wrote:
>On Sun, May 12, 2002 at 09:38:48AM +1000, Keith Owens wrote:
>> 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.

>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.

>> 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.

>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 :)

>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.

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

[george anzinger]

Keith Owens wrote:
> 
> On Sun, 12 May 2002 01:01:21 +0100,
> Russell King <rmk@arm.linux.org.uk> wrote:
> >On Sun, May 12, 2002 at 09:38:48AM +1000, Keith Owens wrote:
> >> 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
-- 
George Anzinger   george@mvista.com
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

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

[george anzinger]

Russell King wrote:
> 
> On Sat, May 11, 2002 at 10:37:39AM -0700, Linus Torvalds wrote:
> > On Sat, 11 May 2002, george anzinger wrote:
> > >
> > > 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.
> 
> --
> Russell King (rmk@arm.linux.org.uk)                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):

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
--- linux-2.5.15-kb2/arch/arm/vmlinux-armo.lds.in	Sun May 12 00:54:48 2002
+++ linux/arch/arm/vmlinux-armo.lds.in	Sun May 12 00:57:01 2002
@@ -4,7 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
-jiffies = jiffies_64 + 4;
+jiffies = jiffies_64;
 SECTIONS
 {
 	. = TEXTADDR;
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
--- linux-2.5.15-kb2/arch/arm/vmlinux-armv.lds.in	Sun May 12 00:54:48 2002
+++ linux/arch/arm/vmlinux-armv.lds.in	Sun May 12 00:57:16 2002
@@ -4,7 +4,7 @@
  */
 OUTPUT_ARCH(arm)
 ENTRY(stext)
-jiffies = jiffies_64 + 4;
+jiffies = jiffies_64;
 SECTIONS
 {
 	. = TEXTADDR;

-- 
George Anzinger   george@mvista.com
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

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

[Daniel Jacobowitz]

On Sat, May 11, 2002 at 08:01:34AM -0700, george anzinger wrote:
> Russell King wrote:
> > 
> > On Fri, May 10, 2002 at 05:42:46PM -0700, george anzinger wrote:
> > > 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
> > > --- linux-2.5.14-org/arch/arm/vmlinux-armo.lds.in     Tue May  7 15:59:35 2002
> > > +++ linux/arch/arm/vmlinux-armo.lds.in        Fri May 10 17:07:31 2002
> > > @@ -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
> > > --- linux-2.5.14-org/arch/arm/vmlinux-armv.lds.in     Tue May  7 15:59:35 2002
> > > +++ linux/arch/arm/vmlinux-armv.lds.in        Fri May 10 17:07:34 2002
> > > @@ -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?
> > 
> 
> >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?

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

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: 64-bit jiffies, a better solution

[Maciej W. Rozycki]

On Fri, 10 May 2002, george anzinger wrote:

> 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.

> 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +