| Message ID | 20240918004731.3295870-1-raj.khem@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | selftests: timers: Fix clock_adjtime for newer 32-bit arches | expand |
On Wed, Sep 18, 2024 at 2:47 AM Khem Raj <raj.khem@gmail.com> wrote: > > Newer 32-bit architectures e.g. riscv32 are using 64-bit time_t > from get go, they have not wired __NR_clock_adjtime at all > valid-adjtimex testcase fails to compile on such architectures. > if this condition is found then use 64-bit adjtime syscall > No major objections here. Though I'm feeling a little forgetful as to why the test is calling the syscall directly instead of going through libc. I suspect it's likely due to the test being written prior to the libc implementation being common? So I wonder if a better fix would be just to drop the local clock_adjtime implementation here, as I'm sure the libc has similar logic to what's being added here? thanks -john
On 9/18/24 02:58, John Stultz wrote: > On Wed, Sep 18, 2024 at 2:47 AM Khem Raj <raj.khem@gmail.com> wrote: >> >> Newer 32-bit architectures e.g. riscv32 are using 64-bit time_t >> from get go, they have not wired __NR_clock_adjtime at all >> valid-adjtimex testcase fails to compile on such architectures. >> if this condition is found then use 64-bit adjtime syscall >> > > No major objections here. Though I'm feeling a little forgetful as to > why the test is calling the syscall directly instead of going through > libc. > I suspect it's likely due to the test being written prior to the libc > implementation being common? > > So I wonder if a better fix would be just to drop the local > clock_adjtime implementation here, as I'm sure the libc has similar > logic to what's being added here? > The proposed solution works better than adding local clock_adjtime implementation here. thanks, -- Shuah
On Thu, Sep 19, 2024 at 10:54 AM Shuah Khan <skhan@linuxfoundation.org> wrote: > > On 9/18/24 02:58, John Stultz wrote: > > On Wed, Sep 18, 2024 at 2:47 AM Khem Raj <raj.khem@gmail.com> wrote: > >> > >> Newer 32-bit architectures e.g. riscv32 are using 64-bit time_t > >> from get go, they have not wired __NR_clock_adjtime at all > >> valid-adjtimex testcase fails to compile on such architectures. > >> if this condition is found then use 64-bit adjtime syscall > >> > > > > No major objections here. Though I'm feeling a little forgetful as to > > why the test is calling the syscall directly instead of going through > > libc. > > I suspect it's likely due to the test being written prior to the libc > > implementation being common? > > > > So I wonder if a better fix would be just to drop the local > > clock_adjtime implementation here, as I'm sure the libc has similar > > logic to what's being added here? > > > > The proposed solution works better than adding local clock_adjtime implementation > here. Thanks, I will prepare and test a v2 by removing the local copy of clock_adjtime. > > thanks, > -- Shuah >
diff --git a/tools/testing/selftests/timers/valid-adjtimex.c b/tools/testing/selftests/timers/valid-adjtimex.c index d500884801d8..ff4ff8b1d127 100644 --- a/tools/testing/selftests/timers/valid-adjtimex.c +++ b/tools/testing/selftests/timers/valid-adjtimex.c @@ -39,7 +39,11 @@ #include <sys/syscall.h> int clock_adjtime(clockid_t id, struct timex *tx) { +#if !defined(__NR_clock_adjtime) && defined(__NR_clock_adjtime64) + return syscall(__NR_clock_adjtime64, id, tx); +#else return syscall(__NR_clock_adjtime, id, tx); +#endif }
Newer 32-bit architectures e.g. riscv32 are using 64-bit time_t from get go, they have not wired __NR_clock_adjtime at all valid-adjtimex testcase fails to compile on such architectures. if this condition is found then use 64-bit adjtime syscall Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: John Stultz <jstultz@google.com> Cc: Shuah Khan <shuah@kernel.org> --- tools/testing/selftests/timers/valid-adjtimex.c | 4 ++++ 1 file changed, 4 insertions(+)