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
..
bitops
4level-fixup.h
atomic-long.h
atomic.h
atomic64.h
audit_change_attr.h	audit: make link()/linkat() match "attribute change" predicate	2010-10-30 08:45:43 -04:00
audit_dir_write.h
audit_read.h
audit_signal.h
audit_write.h
auxvec.h
bitops.h
bitsperlong.h
bug.h
bugs.h
cache.h
cacheflush.h
checksum.h
cmpxchg-local.h
cmpxchg.h
cputime.h
current.h
delay.h
device.h
div64.h
dma-coherent.h
dma-mapping-broken.h
dma-mapping-common.h
dma.h
emergency-restart.h
errno-base.h
errno.h
fb.h
fcntl.h
futex.h
getorder.h
gpio.h
hardirq.h
hw_irq.h
ide_iops.h
int-l64.h
int-ll64.h
io.h
ioctl.h
ioctls.h
iomap.h
ipcbuf.h
irq_regs.h
irq.h
irqflags.h
Kbuild
Kbuild.asm
kdebug.h
kmap_types.h
libata-portmap.h
linkage.h
local.h
local64.h
memory_model.h
mm_hooks.h
mman-common.h
mman.h
mmu_context.h
mmu.h
module.h
msgbuf.h
mutex-dec.h
mutex-null.h
mutex-xchg.h
mutex.h
page.h
param.h
parport.h
pci-dma-compat.h
pci.h
percpu.h
pgalloc.h
pgtable-nopmd.h
pgtable-nopud.h
pgtable.h
poll.h
posix_types.h
resource.h
rtc.h
scatterlist.h
sections.h
segment.h
sembuf.h
serial.h
setup.h
shmbuf.h
shmparam.h
siginfo.h
signal-defs.h
signal.h
socket.h
sockios.h
spinlock.h
stat.h	asm-generic/stat.h: support 64-bit file time_t for stat()	2010-11-01 15:31:29 -04:00
statfs.h
string.h
swab.h
syscall.h
syscalls.h
system.h
termbits.h
termios-base.h
termios.h
timex.h
tlb.h
tlbflush.h
topology.h
types.h
uaccess-unaligned.h
uaccess.h
ucontext.h
unaligned.h
unistd.h
user.h
vga.h
vmlinux.lds.h
xor.h