aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/features/core/BPF-JIT/arch-support.txt
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2018-03-15 13:30:51 +0100
committerArnd Bergmann <arnd@arndb.de>2018-03-26 15:56:06 +0200
commita402ab8cc7b0578c445f348c9010e62ab390bee8 (patch)
tree1f81d4b77b70c44d3b72885788e363fc441bf850 /Documentation/features/core/BPF-JIT/arch-support.txt
parentasm-generic: siginfo: remove obsolete #ifdefs (diff)
downloadlinux-dev-a402ab8cc7b0578c445f348c9010e62ab390bee8.tar.xz
linux-dev-a402ab8cc7b0578c445f348c9010e62ab390bee8.zip
asm-generic: siginfo: define ia64 si_codes unconditionally
Unlike system call numbers the assignment of si_codes has never had a reason to be made per architecture. Some architectures have had unique conditions to report and reporting those conditions needed new si_codes. Nothing has ever needed si_codes to have different values on different architectures. The si_code space is vast so even with defining all si_codes on all architectures there is no danger in running out of si_code values. The history of the si_codes BUS_MCEERR_AR, BUS_MCEER_AO, SEGV_BNDERR, and SEGV_PKUERR show that a need of one architecture frequently becomes a need of another architecture which makes sharing si_codes between architectures a positive benefit and something to be encouraged. Where there are no conflicts with the historical ia64 arch specific si_codes and any other si_codes make them generic si_codes. We might need them on another architecture someday. This leaves only the good example of arch generic si_codes in the kernel for future architectures and architecture enhancments to follow. Without bad examples to follow it should be easy to avoid the mistakes of the past. Reported-by: Eric W. Biederman <ebiederm@xmission.com> [arnd: took Eric's changelog text] Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'Documentation/features/core/BPF-JIT/arch-support.txt')
0 files changed, 0 insertions, 0 deletions