[LTP] Query: Supporting time64 syscalls

[LTP] Query: Supporting time64 syscalls

[Viresh Kumar]

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.

Thanks.

--
viresh

[LTP] Query: Supporting time64 syscalls

[Arnd Bergmann]

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

[LTP] Query: Supporting time64 syscalls

[Viresh Kumar]

On 23-03-20, 14:42, Viresh Kumar 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.

@Cyril/Petr,

Any suggestions on how should I go about these tests ?

-- 
viresh

[LTP] Query: Supporting time64 syscalls

[Cyril Hrubis]

Hi!
> > 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.
> 
> @Cyril/Petr,
> 
> Any suggestions on how should I go about these tests ?

I guess that we can take the existing timer tests and add tests variants
so that we cover all possible cases, I guess that would mean 32bit
kernel syscall, 64bit kernel syscall, glibc wrapper and in some cases
also VDSO.

You can have a look at clock_getres01.c and take it as an example.

-- 
Cyril Hrubis
chrubis@suse.cz