Message-ID: <4CCC88CE.5010006@tilera.com>
Date:	Sat, 30 Oct 2010 17:06:22 -0400
From:	Chris Metcalf <cmetcalf@...era.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	<linux-arch@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Chen Liqin <liqin.chen@...plusct.com>,
	Lennox Wu <lennox.wu@...il.com>,
	Michal Simek <monstr@...str.eu>
Subject: Re: [PATCH] asm-generic/stat.h: support 64-bit file time_t for stat()

On 10/29/2010 2:25 AM, Arnd Bergmann wrote:
> On Thursday 28 October 2010, Chris Metcalf wrote:
>> The alternative is keeping the two structures the same shape on 64-bit
>> kernels, which means a 64-bit time_t in "struct stat64" for 32-bit
>> processes.  This is a little unnatural since 32-bit userspace can't
>> do anything with 64 bits of time_t information, since time_t is just
>> "long", not "int64_t"; and in any case 32-bit userspace might expect
>> to be running under a 32-bit kernel, which can't provide the high 32
>> bits anyway.  In the case of a 32-bit kernel we'd then be extending the
>> kernel's 32-bit time_t to 64 bits, then truncating it back to 32 bits
>> again in userspace, for no particular reason.  And, as mentioned above,
>> if we have 64-bit time_t for 32-bit processes we can't easily use glibc's
>> STAT_IS_KERNEL_STAT, since glibc's stat structure requires an embedded
>> "struct timespec", which is a pair of "long" (32-bit) values in a 32-bit
>> userspace.  "Inventive" solutions are possible, but are pretty hacky.
> I'd like to have more opinions on that. Would it be less crazy
> to ignore the y2k38 problem for new 32 bit architectures given that
> we already know about it, or to make those architectures unnecessarily
> slow, given that we still have 27+ years before it hits people in
> a major way?
>
> I think we have four alternatives here:
>
> 1. this patch, which is the easiest solution and keeps everything else
> working, but not solving the y2k38 problem on 32 bit.

Perhaps unsurprisingly, I think this patch strikes a good balance for today
of allowing <asm-generic/stat.h> to work in the "obviously correct" way for
64-bit platforms, but without addressing the larger issues.

> 2. make __kernel_time_t 64 bit on new architectures, solving the y2k38
> problem for them at the cost of run-time overhead and possibly application
> porting effort.
>
> 3. make struct stat use a 64 bit time field on new architectures at the
> cost of not using STAT_IS_KERNEL_STAT in 32 bit glibc.
>
> 4. leave struct stat as it is, and move to struct xstat that does
> everything right from the start.

I'd argue that the longer-term plan might be to work with the glibc
community to spec out what the eventual 64-bit time_t APIs will look like
for user-space, and then think about implementing them using xstat() with
64-bit time_t.  Once this is in place, the kernel will need to move to
64-bit __kernel_time_t enough in advance of 2038 to hope that it's
widely-deployed in embedded systems, etc., by then.  But I think this all
represents a more ambitious project than we need today.

> Your patch looks correct for solution 1, I can forward it if we decide
> to do it this way, or you can take it in your series.
>
> Acked-by: Arnd Bergmann <arnd@...db.de>

Thanks!

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists