linux/arch/tile/include/asm
Chris Metcalf 2c7387ef99 asm-generic/stat.h: support 64-bit file time_t for stat()
The existing asm-generic/stat.h specifies st_mtime, etc., as a 32-value,
and works well for 32-bit architectures (currently microblaze, score,
and 32-bit tile).  However, for 64-bit architectures it isn't sufficient
to return 32 bits of time_t; this isn't good insurance against the 2037
rollover.  (It also makes glibc support less convenient, since we can't
use glibc's handy STAT_IS_KERNEL_STAT mode.)

This change extends the two "timespec" fields for each of the three atime,
mtime, and ctime fields from "int" to "long".  As a result, on 32-bit
platforms nothing changes, and 64-bit platforms will now work as expected.

The only wrinkle is 32-bit userspace under 64-bit kernels taking advantage
of COMPAT mode.  For these, we leave the "struct stat64" definitions with
the "int" versions of the time_t and nsec fields, so that architectures
can implement compat_sys_stat64() and friends with sys_stat64(), etc.,
and get the expected 32-bit structure layout.  This requires a
field-by-field copy in the kernel, implemented by the code guarded
under __ARCH_WANT_STAT64.

This does mean that the shape of the "struct stat" and "struct stat64"
structures is different on a 64-bit kernel, but only one of the two
structures should ever be used by any given process: "struct stat"
is meant for 64-bit userspace only, and "struct stat64" for 32-bit
userspace only.  (On a 32-bit kernel the two structures continue to have
the same shape, since "long" is 32 bits.)

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.

Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
2010-11-01 15:31:29 -04:00
..
Kbuild
asm-offsets.h
atomic.h
atomic_32.h
auxvec.h
backtrace.h
bitops.h
bitops_32.h
bitsperlong.h
bug.h
bugs.h
byteorder.h
cache.h
cacheflush.h
checksum.h
compat.h
cputime.h
current.h
delay.h
device.h
div64.h
dma-mapping.h
dma.h
elf.h
emergency-restart.h
errno.h
fcntl.h
fixmap.h
ftrace.h
futex.h
hardirq.h
hardwall.h
highmem.h
homecache.h
hugetlb.h
hv_driver.h
hw_irq.h
ide.h
io.h
ioctl.h
ioctls.h
ipc.h
ipcbuf.h
irq.h
irq_regs.h
irqflags.h
kdebug.h
kexec.h
kmap_types.h
linkage.h
local.h
memprof.h
mman.h
mmu.h
mmu_context.h
mmzone.h
module.h
msgbuf.h
mutex.h
opcode-tile.h
opcode-tile_32.h
opcode-tile_64.h
opcode_constants.h
opcode_constants_32.h
opcode_constants_64.h
page.h
param.h
pci-bridge.h
pci.h
percpu.h
pgalloc.h
pgtable.h
pgtable_32.h
poll.h
posix_types.h
processor.h
ptrace.h
resource.h
scatterlist.h
sections.h
sembuf.h
setup.h
shmbuf.h
shmparam.h
sigcontext.h
sigframe.h
siginfo.h
signal.h
smp.h
socket.h
sockios.h
spinlock.h
spinlock_32.h
spinlock_types.h
stack.h
stat.h
statfs.h
string.h
swab.h
syscall.h
syscalls.h
system.h
termbits.h
termios.h
thread_info.h
timex.h
tlb.h
tlbflush.h
topology.h
traps.h
types.h
uaccess.h
ucontext.h
unaligned.h
unistd.h
user.h
xor.h