Re: [PATCH v3 5/7] time: Add struct __kernel_timex

[Arnd Bergmann]

On Thu, Jul 12, 2018 at 10:26 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

>> +#ifndef CONFIG_64BIT_TIME
>> +#define __kernel_timex timex
>> +#endif
>
> using #defines for structs has all kinds of ill effects.  Why can't
> we aways use __kernel_timex for the in-kernel usage?

It's the same thing that Deepa did in the already merged
series for the timespec interfaces, this is done in order to
stage the conversion of 50 system calls and 20 architectures
without having to do everything at once.

The system call entry points are changed to take a __kernel_timespec
or __kernel_timex argument as the first step, and the conditional
macro override makes that a NOP. At the same time, the existing
compat entry points are modified so they have the exact same
behavior but use the compat_timespec, compat_timex etc
argument types (which we can rename, too, as discussed).

When a 32-bit architecture gets converted, it sets
CONFIG_64BIT_TIME, which flips the normal syscall entry to
use 64-bit time_t, and enables the compat syscalls to be built.
The same arch specific patch must then change the syscall
table to redirect the old syscall numbers to the compat handlers
(which implement the 32-bit time_t arguments), and add new
numbers pointing to the default handlers that now take the
64-bit time_t, see https://pastebin.com/F3QZdyin

This was all explained in a lot of detail when the first set
of patches got merged for the clock_ syscalls, but I suppose
it can all be explained again.

>> +#ifndef __kernel_timex
>> +struct __kernel_timex {
>> +     unsigned int modes;     /* mode selector */
>> +     int :32;            /* pad */
>
> Why do we need padding for a purely in-kernel structure?
>
> Also the anonymous member syntax is rather odd and I don't remeber
> us using it anywhere else.  Why here?

This is in the uapi header, and the structure just matches the
existing timex definition, which has the same oddity.

     Arnd