On 05/30/2014 01:01 PM, Arnd Bergmann wrote:
> +#ifdef CONFIG_NEW_INODE_TIME
> +/*
> + * This is the type we use internally in the kernel to represent
> + * absolute times in file system metadata.
> + * This structure must not leak out to user space, and new interfaces
> + * should be using 64-bit types right away.
> + */
> +
> +/*
> + * Variant a) using unsigned seconds lets us extend the life span
> + * for another 69 years beyond 2038.
> + */
> +struct inode_time {
> + unsigned long tv_sec;
> + long tv_nsec;
> +};
This now differs between 32- and 64-bit systems, and on 32-bit systems
some timestamps well within the range of representation of current
systems just became unrepresentable, which is something that I thought
people were objecting very strongly to.
> +#elif 0
> +/*
> + * This variant can represent the widest range of times, but also
> + * bloats 'struct inode' a little more.
> + */
> +struct inode_time {
> + long long tv_sec __attribute__((packed));
> + int tv_nsec;
> +};
Seriously, though, can we really impose constraints stricter than what
the filesystems themselves do? It seems we ought to be able to
represent whatever time the filesystem can represent... (modulo some
kind of window control as Y2038 or any other break point approaches.)
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
