[PATCH] arm64: perf: fix syscalltbl path base

[James Clark]

On 15/12/2025 11:33, Arnd Bergmann wrote:
> On Mon, Dec 15, 2025, at 09:47, James Clark wrote:
>> On 15/12/2025 00:12, Joel May wrote:
>>
>> Hi Joel,
>>
>> There is a similar fix on the list here:
>>
>> https://lore.kernel.org/linux-perf-users/20251204-perf_fix_syscall_header-v1-1-b8e27f74ed6a@arm.com/
>>
>> I'm not sure if commit 1 alone will also fix your issue, or we'd need to
>> collapse both of the commits in that set.
>>
>> The first commit has an older fixes: tag and also fixes some other
>> issues so it might be better to take that one rather than this one.
> 
> I don't understand that other "fix", doesn't that just work around
> the arm64 build issue by adding another special case for arm64?
> 
> If we want the tools directory to have a copy of the generated unistd.h
> files instead of generating them, it should at the minimum be done
> the same across all architectures.
> 
>      Arnd

I don't think it's a special case, the other architectures already have 
a copy of their syscall headers in tools/ don't they?

My original commit that is reverted by Leo's patches is more of a "fix" 
than his fix. It turned out that running the generator script for the 
Perf build wasn't the best idea after all. Now it's obvious that we'd 
have to keep injecting that build rule into every tool that needs it. 
And it doesn't even respect this rule described here that tools headers 
should be decoupled from the kernel sources:

  linux/tools/include/uapi/README

I don't see the benefit of manually copying over the generator script 
and its input file and then updating every build rule to invoke it when 
we can manually copy over the output of that script and not have to do 
anything else.

Ian makes the point that we can run the generator for doing 
check_headers.sh. But at least that only needs to be done for one tool 
and can be in addition to the manual copy.

James