Skip to content

lib: add loongarch64 processor support - #559

Open
debianyu wants to merge 1 commit into
linux-audit:masterfrom
debianyu:loongarch64-support
Open

debianyu wants to merge 1 commit into
linux-audit:masterfrom
debianyu:loongarch64-support

Conversation

@debianyu

Copy link
Copy Markdown

Add LoongArch64 (loongarch64) processor support to libaudit, following the same pattern as RISCV64 and
AARCH64.

  • New file: lib/loongarch64_table.h (326 syscall entries)

Tested on x86_64 host with loongarch64 cross-compiler (GCC 15.1.0):
autoreconf, configure, make, lookup_test all pass.

Closes: #88

Add LoongArch64 (EM_LOONGARCH 258) support to the audit library,
following the pattern used by aarch64 and riscv.

The LoongArch64 architecture uses the generic syscall ABI (same as
riscv64), so the syscall table is derived from the riscv64 table
minus RISC-V-specific syscalls.

This includes:
- configure.ac: --with-loongarch64 option and WITH_LOONGARCH64 define
- lib/libaudit.h: MACH_LOONGARCH64 in machine_t enum
- lib/libaudit.c: machine determination for loongarch64 (64-bit only)
- lib/lookup_table.c: elf table entry and s2i/i2s dispatch
- lib/machinetab.h: machine name mapping
- lib/Makefile.am: build rules for loongarch64_tables.h
- lib/test/lookup_test.c: table validation test
- lib/syscall-update.txt: syscall source documentation
- lib/loongarch64_table.h: 326 syscall entries (new file)

Signed-off-by: YuPeng <yupeng@kylinos.cn>
@debianyu

Copy link
Copy Markdown
Author

Hi, gentle ping on this PR. Is there anything that needs to be adjusted? Thanks!

@stevegrubb

Copy link
Copy Markdown
Contributor

Well, first thing is that there is a moratorium on adding new hardware platforms because I have no time for adding syscalls every kernel release. This was announced on the mail list a couple years ago:

https://lore.kernel.org/linux-audit/4855993.31r3eYUQgx@x2/T/#u

See item 6.MIPS was let in because they promised to update the tables.

@debianyu

Copy link
Copy Markdown
Author

Thanks for the explanation, Steve. I understand the maintenance burden concern.

loongarch64 is an actively deployed architecture in production, and I'm willing to commit to keeping syscall-names.list and
the loongarch64 syscall table updated for each kernel release, the same way MIPS was let in with that commitment.

Would that be acceptable? Or would you prefer me to resubmit this after the moratorium is lifted?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants