diff options
author | Arnd Bergmann <arnd@arndb.de> | 2018-03-15 13:30:51 +0100 |
---|---|---|
committer | Arnd Bergmann <arnd@arndb.de> | 2018-03-26 15:56:06 +0200 |
commit | a402ab8cc7b0578c445f348c9010e62ab390bee8 (patch) | |
tree | 1f81d4b77b70c44d3b72885788e363fc441bf850 /Documentation/admin-guide | |
parent | asm-generic: siginfo: remove obsolete #ifdefs (diff) | |
download | linux-a402ab8cc7b0578c445f348c9010e62ab390bee8.tar.xz linux-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/admin-guide')
0 files changed, 0 insertions, 0 deletions