Re: [Patch] Re: Nasty suprise with uptime

vda (vda@port.imtp.ilyichevsk.odessa.ua)
Wed, 31 Oct 2001 15:39:00 +0000


On Wednesday 31 October 2001 11:35, Tim Schmielau wrote:
> The appended patch enables 32 bit linux boxes to display more than
> 497.1 days of uptime. No user land application changes are needed.
>
> Credit is due to George Anzinger and the High-res-timers project
> at https://sourceforge.net/projects/high-res-timers/, where I ripped
> out the 64 bit jiffies patch. However, I do claim ownership on
> all misdesign and bugs since this is my first kernel patch.
>
> My Intel box just now displays a (faked, of course) uptime of 497 days,
> 2:38 hours, so the 32 jiffies value has wrapped without problems about 10
> minutes ago.
>
> Next step would be to decide what to do with the start_time field of
> struct task_struct, which is still 32 bit, so ps on my box believes some
> processes to have started 497 days ago. Probably there are tons of other
> uses for the upper 32 bit of jiffies as well.

Hmm.... 64bit jiffies are attractive.

I'd like to see less #defines in kernel
Some parts of your patch fight with the fact that jiffies
is converted to macro -> it is illegal now to have local vars
called "jiffies". This is ugly. I know that there are tons of similarly
(ab)used macros in the kernel now but let's stop adding more!

This test prog shows how to make overlapping 32bit and 64bit vars.
It works for me.

#include <stdio.h>
typedef unsigned long long u64;

extern u64 jiffies_64;
extern unsigned long jiffies;
extern unsigned long jiffies_hi;

asm(
" .bss\n"
" .align 8\n"
".globl jiffies_64\n"
".globl jiffies\n"
".globl jiffies_hi\n"
"jiffies_64:\n"
// <- a bunch of ifdefs needed here to sort out endianness stuff...
"jiffies:\n"
" .zero 4\n"
"jiffies_hi:\n"
" .zero 4\n"

//not working!? how to return to prev .data/.text/whatever?
//I don't know gas...
//" .previous\n"
);

int main() {
jiffies_64 = 0xFEDCBA9876543210UL;
printf("lo: 0x%08x\n",jiffies);
printf("hi: 0x%08x\n",jiffies_hi);
return 0;
}

Is this better or not? If not, why?

--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/