lkml.org 
[lkml]   [2004]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
Date
From
Andi Kleen writes:
> The solution from back then I actually liked best was to just round
> up to the next second instead of rounding down when going from 1s
> resolution to ns.

(My understanding of kernel internals is way rusty, so if I am
talking nonsense here, just hit me with a cluestick or ignore
me or something).

Ummm, I think that will just fail in the converse way if
insn-conditions.o is retained in the inode cache while
insn-conditions.c is dropped from the cache?

That is, consider these time-stamps:

insn-conditions.c SSSS.NS1
insn-conditions.o SSSS.NS2

Where SSSS is the same value on both files, and NS2 > NS1.

According to Ulrich, the current problem is that insn-conditions.o
is dropped from the cache, so NS2 becomes 0, and insn-conditions.o
becomes older than insn-conditions.c.

With your patch, suppose that insn-conditions.c is dropped from the
cache, while insn-conditions.o remains. Then the timestamps will be:

insn-conditions.c SSSS+1.0
insn-conditions.o SSSS.NS2

We lose again, insn-conditions.c has become newer than insn-conditions.o.

insn-conditions.c is a generated file so I think this can actually
happen during a gcc build.

Michael C
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.012 / U:2.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site