[LTP] [PATCH v4 4/4] Update syscalls files

[Andrea Cervesato]

Hi Petr,

On 10/15/24 19:17, Petr Vorel wrote:
> 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.
Ok, now I see the point. Well, we can make a decision around it then, 
but it will probably need more people involved.
> 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
This is really strange. It's not happening for me even with the latest 
HEAD. Did you rebase first?
> Kind regards,
> Petr
Andrea