[LTP] Query: Supporting time64 syscalls

Arnd Bergmann arnd@arndb.de
Mon Mar 23 10:30:55 CET 2020


On Mon, Mar 23, 2020 at 10:12 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> Hi guys,
>
> I was looking to start working on the time64 syscalls
> (like clock_gettime64, timerfd_settime64, etc) and
> was looking for your suggestions on how to proceed on
> the same.
>
> AFAIU, the only difference is that the argument is 64 bit now
> instead of 32 bit and so I don't think I should be adding new
> tests but reusing the existing ones for both 32 bit and 64 bit
> variants.

I agree the tests should generally be the same in both cases.
However, there are a couple of other considerations:

- at the moment (at least when I last checked in summer 2019),
  there are two sets of tests: one for the libc interfaces and one
  for the low-level kernel interfaces.

- the low-level kernel interface tests use the type definitions from
  libc, which are wrong when building with 64-bit time_t, making
  all those tests fail or hang.

- I think we need to test all four combinations,
  - the existing 32-bit time_t libc interfaces (only on 32-bit architectures)
    with -D_TIME_BITS=32
  - the new 64-bit time_t libc interfaces with -D_TIME_BITS=64
  - the low-level kernel syscalls with 'typedef long __kernel_old_time_t'
    if the non-_time64 syscall numbers are defined
  - the low-level kernel syscalls with ''typedef long long __kernel_time64_t'
    if the _time64 syscall numbers are defined

- there may be some useful tests one can do on the _time64 syscalls
  to ensure that they actually work with the expected ranges, such as
  .tv_sec = 0x100000000ll' or .tv_sec = '0x7fffffffffffffffll', or explicitly
  bogus data in the padding field around .tv_nsec.

        Arnd


More information about the ltp mailing list