[LTP] [PATCH v4 4/4] Update syscalls files
Petr Vorel
pvorel@suse.cz
Tue Oct 15 19:17:17 CEST 2024
Hi Andrea, Li, all,
> Hi All,
> On Tue, Oct 15, 2024 at 2:49 PM Li Wang <liwang@redhat.com> wrote:
> > Andrea Cervesato <andrea.cervesato@suse.de> wrote:
> > Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
> >> ---
> >> include/lapi/syscalls/arc.in | 41 +-
> >> include/lapi/syscalls/arm.in | 819
> >> ++++++++++++++++++-----------------
> >> include/lapi/syscalls/arm64.in | 18 +-
> >> include/lapi/syscalls/i386.in | 18 +-
> >> include/lapi/syscalls/ia64.in | 10 +-
> > The mainline kernel has dropped support for Itanium IA-64 from kernel-v6.7
> > .
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf8e8658100d4eae80ce9b21f7a81cb024dd5057
> > I'm wondering if we should remove IA64 support for LTP as well.
> > But whatever LTP keeps the code for IA64 or not, maybe we don't
> > need these update for ia64, right?
> BTW, The below link here may not be directly relevant to your patch,
> but I think of we have discussed cleaning up the IA64 code in LTP before.
> https://lists.linux.it/pipermail/ltp/2024-January/036611.html
Yes, it's time to drop IA64 code (as a separate effort, there are #ifdef).
It would be cleaner if you instead of modifying ia64.in just remove the file in
a separate commit before (unrelated change). But I'm ok also with single commit
if you're not going to send another version.
I also wonder if we should add PA-RISC, HP stop supporting servers in 2013 [1].
Sure, kernel is still contains this arch, but I doubt anybody uses LTP for
testing. The arch is IMHO not supported directly by any distro (it was dropped
from Debian 6 squeeze [2], which was released 2011 and EOL 2016), moved to
Debian ports [3]. The community is still somehow active, but few people just
fight to fix compilation issues [4].
Sure, it's jut a single file (parisc.in) and we have other legacy architectures
which are passing away but not yet removed from kernel tree due few people using
them (at least sh, s390, sparc). Having these files we suggest somebody is
actually taking care about these archs. But as I said, probably nobody is using
LTP to test them, thus many tests will be broken.
[1] https://en.wikipedia.org/wiki/PA-RISC
[2] https://www.debian.org/ports/hppa/
[3] https://lists.debian.org/debian-hppa/
[4] https://lists.debian.org/debian-hppa/2024/09/threads.html
Also, this 4th patch also does not apply. Unlike first commit there are more
conflicts (applying of course on the top of the 3 previous patches):
Description: [v4,4/4] Update syscalls files
Applying: Update syscalls files
error: patch failed: include/lapi/syscalls/arm.in:1
error: include/lapi/syscalls/arm.in: patch does not apply
error: patch failed: include/lapi/syscalls/arm64.in:294
error: include/lapi/syscalls/arm64.in: patch does not apply
error: patch failed: include/lapi/syscalls/ia64.in:341
error: include/lapi/syscalls/ia64.in: patch does not apply
error: patch failed: include/lapi/syscalls/x86_64.in:349
error: include/lapi/syscalls/x86_64.in: patch does not apply
Patch failed at 0001 Update syscalls files
Kind regards,
Petr
More information about the ltp
mailing list