From mboxrd@z Thu Jan  1 00:00:00 1970
From: H. Peter Anvin <hpa@zytor.com>
Date: Wed, 04 Jun 2014 17:10:24 -0700
Subject: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready
In-Reply-To: <8770583.6XeZxCxOY8@wuerfel>
References: <1401480116-1973111-1-git-send-email-arnd@arndb.de>
	<201406041703.47592.arnd@arndb.de>
	<alpine.LFD.2.11.1406041308300.17310@knanqh.ubzr>
	<8770583.6XeZxCxOY8@wuerfel>
Message-ID: <538FB570.8000502@zytor.com>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On 06/04/2014 12:24 PM, Arnd Bergmann wrote:
> 
> For other timekeeping stuff in the kernel, I agree that using some
> 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
> ...) has advantages, that's exactly the point I was making earlier
> against simply extending the internal time_t/timespec to 64-bit
> seconds for everything.
> 

How much of a performance issue is it to make time_t 64 bits, and for
the bits there are, how hard are they to fix?

	-hpa