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
* 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.
* 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.
> > I would also prefer not too many people to work on the syscalls, and
> > would rather have Baolin not touch any of the syscall prototypes for
> > the moment.
>
> I did not ask him to change any of the syscall prototypes. I just
> wanted him to split out the guts of the syscall into a seperate static
> function to avoid all that code churn.
Ok, I wasn't sure about that part, thanks for clarifying.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
