Messages in this thread | | | Subject | Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build | Date | Thu, 1 Apr 2004 15:51:33 -0500 (EST) | From | (Michael Elizabeth Chastain) |
| |
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/
| |