From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 3/5] syscalls: Don't use tst_syscall() unnecessarily
Date: Thu, 21 May 2020 16:20:37 +0200 [thread overview]
Message-ID: <20200521142037.GC7833@yuki.lan> (raw)
In-Reply-To: <20200520071948.qtuzbfesqvcnsizd@vireshk-i7>
Hi!
> > 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.
>
> To conclude the discussion, is this patch okay or not ? The reason why I am
> asking this is because this file still uses the old test framework and so can't
> include tst_timer.h, and so doesn't have access to struct __kernel_old_timespec.
>
> What do you suggest I do here ?
Well if it was only about __kernel_old_timespec we could easily just
declare it locally in the file and be done with it.
But I guess that newer 32bit architectures will have only the 64 bit
syscall present, I think that somebody pointed out that this is the case
for 32bit RiscV. If that's true we will have to have a fallback for that
case as well.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2020-05-21 14:20 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
2020-05-20 7:19 ` Viresh Kumar
2020-05-21 14:20 ` Cyril Hrubis [this message]
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=20200521142037.GC7833@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.