xfs
[Top] [All Lists]

Re: [RFC 11/32] xfs: convert to struct inode_time

To: "H. Peter Anvin" <hpa@xxxxxxxxx>
Subject: Re: [RFC 11/32] xfs: convert to struct inode_time
From: Arnd Bergmann <arnd@xxxxxxxx>
Date: Mon, 02 Jun 2014 13:02:07 +0200
Cc: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, joseph@xxxxxxxxxxxxxxxx, john.stultz@xxxxxxxxxx, hch@xxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, geert@xxxxxxxxxxxxxx, lftan@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <0ab4392c-d89d-4277-914d-1696f455daab@xxxxxxxxxxxxxxxxx>
References: <1401480116-1973111-1-git-send-email-arnd@xxxxxxxx> <8618458.1EVJCoVbkH@wuerfel> <0ab4392c-d89d-4277-914d-1696f455daab@xxxxxxxxxxxxxxxxx>
User-agent: KMail/4.11.5 (Linux/3.11.0-18-generic; KDE/4.11.5; x86_64; ; )
On Sunday 01 June 2014 13:26:03 H. Peter Anvin wrote:
> Perhaps we should make this a kernel command line option instead, with the
> settings: error out on outside the standard window, or a date indicating the
> earliest date that should be recognized and do windowing (0 for no windowing,
> 1970 for retconning the Unix epoch as unsigned...)

What's wrong with compile-time errors? We have a pretty good understanding
of how time values are passed in the kernel, and we know they will all break
in 2038 for 32-bit kernels unless we do something about it.
 
> But again, the kernel is probably the least problem here...
 
I agree the glibc side is harder than this, but we have to get the kernel
into shape first (at the minimum we have to do the APIs), and there is enough
work to do here.

        Arnd

<Prev in Thread] Current Thread [Next in Thread>