Re: [PATCH v3 1/3] tools headers: Go back to include asm-generic/unistd.h for arm64

[Leo Yan <leo.yan@arm.com>]

On Wed, Dec 24, 2025 at 01:47:51PM +0000, James Clark wrote:

[...]

> > To fix the issue, it restores to include asm-generic/unistd.h.  This is
> 
> Would this prevent us from using any Arm64 specific syscalls in the future?

I hope the perf code can be general enough so don't call arch specific
syscalls.

> I think that's a downside of this approach vs copying the generated output
> that should be noted here.

From pragmatic view, I don't see any issue with using the
asm-generic/unistd.h on Arm64 at current stage.

If later we need to support new syscalls, I assume it is very likely not
an issue for Arm64 specific, we need to resolve common issue either
updating asm-generic/unistd.h or change to use dynamic generated headers.

> > consistent with other architectures and ensures the header is available
> 
> 'Consistent' isn't accurate is it? x86 already has static copies of syscalls
> in tools/arch/x86/include/uapi/asm/unistd_32.h and
> tools/arch/x86/include/uapi/asm/unistd_64.h.

I went through a bit x86's unistd_32.h/unistd_64.h, it defines some
special syscall numbers.  Seems removing them will break on x86.
I'd leave this to x86 maintainers.

To avoid confusion, I will update the commit log:

  Restore to include asm-generic/unistd.h for fixing the issue.  This
  aligns with most architectures (x86 is a special case that keeps
  unistd_32.h/unistd_64.h for its particular syscall numbers) and
  ensures the header is available from the start.

> Maybe something more like "eventual consistency" is intended, if we plan to
> remove those x86 headers too?

Yes.

> I'm still a bit lost about why Arm64 copying
> the generated header is considered a special case when we already have these
> x86 ones.

If arm64 maintains its own unistd.h, there is a concern that other
architectures will do the same, and we will end up maintaining
fragmented headers for each architecture.

Later, if we need to support architecture specific syscalls, we should
explore better approaches, such as using generated headers (e.g.,
make headers) to provide UAPI headers instead.

IMO, in this case, x86 is not a good example to follow.

Thanks,
Leo