On Mon, May 14, 2018 at 10:25 AM, Deepa Dinamani deepa.kernel@gmail.com wrote:
On Mon, May 14, 2018 at 9:30 AM, Kees Cook keescook@chromium.org wrote:
On Sun, May 13, 2018 at 9:05 PM, Deepa Dinamani deepa.kernel@gmail.com wrote:
Kees mentioned that he wants to merge a patch to pstore that changes it to use timespec64 internally for 4.17: https://lkml.org/lkml/2018/5/13/3
I'm still working on a v2 for pstore. What is the correct cross-architecture format string for timespec64's tv_sec? In your other patches, you're using %lld and a (long long) cast. I'd really like to avoid the need for casts.
We cannot really avoid it for now. struct timespec64 is defined this way for now:
struct timespec { __kernel_time_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ };
#if __BITS_PER_LONG == 64 /* this trick allows us to optimize out timespec64_to_timespec */ # define timespec64 timespec
#else
struct timespec64 { time64_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ };
#endif
This will all lead to tv_sec being long on a 64 bit architecture and long long on a 32 bit architecture. So there is no way of avoiding the cast for now.
We plan to get rid of this trick and to have a single definition for timespec64. But, that cleanup is planned for later when we cleanup all struct timespec uses internally.
Can we do something like:
#if __BITS_PER_LONG == 64 # define TVSEC_FMT "%ld" #else # define TVSEC_FMT "%lld" #endif
so we can do stuff like: sprintf(buf, "seconds: " KTIME_FMT, time->tv_sec)
? It seems easier to clean up than casts.
-Kees