public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 3/5] syscalls: Don't use tst_syscall() unnecessarily
Date: Tue, 19 May 2020 15:45:11 +0200	[thread overview]
Message-ID: <20200519134511.GD16008@yuki.lan> (raw)
In-Reply-To: <CAK8P3a2PgjYyijH=VoNGhs_xk1VvFN6ZNvNM-W4TopWY6jJNbA@mail.gmail.com>

Hi!
> > > -     tst_clock_gettime(CLOCK_MONOTONIC, &ts);
> > > +     clock_gettime(CLOCK_MONOTONIC, &ts);
> >
> > I guess that this will reintroduce LTP compilation failures on older
> > glibc, which was the primary reason we used the tst_clock_gettime()
> > instead of clock_gettime().
> 
> I see that clock_gettime was first added in glibc-2.1.3 back in 1999.
> Can that actually run LTP any more? If it can and this is considered
> important, I fear the tst_clock_gettime() call needs to be extended
> to call the clock_gettime()/clock_gettime64()/gettimeofday() syscalls,
> whichever is the first to work, and convert the formats from the
> native kernel format to the glibc format.

I guess that at the current time we do support distros that are at max
10 years old, mostly because enterprise support cycles are about 10
years in lenght.

The issue here is that glibc needed -lrt passed to linker couple of
years ago and we wanted to avoid the need of linking everything with
-lrt, as calling the raw syscall was just easier fix.

-- 
Cyril Hrubis
chrubis@suse.cz

  parent reply	other threads:[~2020-05-19 13:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  8:51 [LTP] [PATCH 0/5] syscalls: Remove incorrect usage of libc structures Viresh Kumar
2020-05-19  8:51 ` [LTP] [PATCH 1/5] tst_safe_clocks: Remove safe_clock_adjtime() Viresh Kumar
2020-05-19  8:51 ` [LTP] [PATCH 2/5] syscalls: settimeofday: Use gettimeofday() Viresh Kumar
2020-05-19  9:20   ` Arnd Bergmann
2020-05-19  9:25     ` Viresh Kumar
2020-05-19 10:24       ` Arnd Bergmann
2020-05-19 12:16   ` Cyril Hrubis
2020-05-19 12:47     ` Arnd Bergmann
2020-05-20  7:16     ` Viresh Kumar
2020-05-21 13:16       ` Cyril Hrubis
2020-05-19  8:51 ` [LTP] [PATCH 3/5] syscalls: Don't use tst_syscall() unnecessarily Viresh Kumar
2020-05-19  9:22   ` Arnd Bergmann
2020-05-19  9:28     ` Viresh Kumar
2020-05-19 12:23   ` Cyril Hrubis
2020-05-19 12:41     ` Arnd Bergmann
2020-05-19 12:56       ` Petr Vorel
2020-05-19 13:45       ` Cyril Hrubis [this message]
2020-05-20  7:19         ` Viresh Kumar
2020-05-21 14:20           ` Cyril Hrubis
2020-05-21 15:10             ` Arnd Bergmann
2020-05-19  8:51 ` [LTP] [PATCH 4/5] syscalls: Don't pass struct timespec to tst_syscall() Viresh Kumar
2020-05-19 12:21   ` Cyril Hrubis
2020-05-20  7:31     ` Viresh Kumar
2020-05-20  8:47       ` Arnd Bergmann
2020-05-20  9:05         ` Viresh Kumar
2020-05-20  9:35           ` Arnd Bergmann
2020-05-20  9:39             ` Viresh Kumar
2020-05-20  9:52               ` Arnd Bergmann
2020-05-19  8:51 ` [LTP] [PATCH 5/5] syscalls: Don't pass struct timeval " Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200519134511.GD16008@yuki.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox