To: ak@suse.de, gcc@gcc.gnu.org, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
Message-Id: <20040401205133.6C94F4B104@berman.michael-chastain.com>
Date: Thu,  1 Apr 2004 15:51:33 -0500 (EST)
From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1436
Lines: 41

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/