Thread (15 messages) flat view 15 messages, 6 authors, 2023-05-11

Re: [PATCH v13 2/3] cachestat: implement cachestat syscall

From: "Arnd Bergmann" <arnd@arndb.de>
Date: 2023-05-06 17:35:39
Also in: linux-mm, lkml

On Fri, May 5, 2023, at 22:34, Andrew Morton wrote:
On Thu, 4 May 2023 19:26:11 +0200 Geert Uytterhoeven 
[off-list ref] wrote:
quoted
quoted
 arch/x86/entry/syscalls/syscall_32.tbl |   1 +
 arch/x86/entry/syscalls/syscall_64.tbl |   1 +
This should be wired up on each and every architecture.
Currently we're getting

    <stdin>:1567:2: warning: #warning syscall cachestat not implemented [-Wcpp]

in linux-next for all the missing architectures.
Is that wise?  We risk adding a syscall to an architecture without the
arch maintainers and testers even knowing about it.

The compile-time nag is there to inform the arch maintainers that a new
syscall is available and that they should wire it up, run the selftest
and then ship the code if they're happy with the result.
The usual approach is for the author of a new syscall to
include a patch with all the architecture specific changes
and Cc the architecture maintainers for that.

Note that half the architectures get the entry from
include/uapi/asm-generic/unistd.h, so adding it there
does not necessarily trigger adding each maintainer
from scripts/get_maintainer.pl.

The only real risk in adding a new syscall is passing __u64
register arguments that behave differently across
architectures, or using pointers to data structures that
require a compat handler on some architectures. I watch out
for those as they get sent to me or the linux-arch list,
and this one is fine.

     Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help