On Tue, 21 Apr 2015, Arnd Bergmann wrote:
On Tuesday 21 April 2015 16:14:26 Thomas Gleixner wrote:
Note the use of a separate __kernel_itimerspec64 for the user interface here, which I think will be needed to hide the differences between the normal itimerspec on 64-bit machines, and the new itimerspec on 32-bit platforms that will be defined differently (using 'long long').
Confused.
timespec64 / itimerspec64 should be the same independent of 64bit and 32bit. So why do we need another variant ?
There are multiple reasons:
- On 64-bit systems, timespec64 would always be defined in the same way as struct timespec { __kernel_time_t tv_sec; long tv_nsec; }, with __kernel_time_t being 'long'. On 32-bit, we probably need to make both members 'long long' for the user space side, in order to share the syscall implementation with the kernel side, but we may also want to keep the internal timespec64 using a 'long' for tv_nsec, as we do today. This means that both the binary layout (padding or no padding) and the basic types (long or long long) are different between 32-bit and 64-bit, and between kernel and user space
So you want to avoid a compat syscall for 32bit applications on a 64bit kernel, right?
That burdens 32bit with the extra 'long long' in user space. Not sure whether user space folks will be happy about it.
- We should not put 'struct timespec64' into the user space namespace, as applications might already use that identifier. This is similar to the __u32/u32 or __kernel_time_t/time_t tuple of types for interface and in-kernel uses. This is particularly important when embedding a timespec in another data structure.
Fair enough.
- My plan is to use a temporary hack where I actually define __kernel_timespec64 to look like the 32-bit version of timespec, as an intermediate step when converting all 32-bit architectures over to use the compat_*() syscalls in place of the existing ones, so I can change over the normal syscalls to use __kernel_timespec64 without having to change all architectures at once, or having to modify each syscall multiple times.
Makes sense.
Thanks,
tglx