lkml.org 
[lkml]   [2018]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 12/16] asm-generic: siginfo: remove obsolete #ifdefs
Arnd Bergmann <arnd@arndb.de> writes:

> On Thu, Mar 15, 2018 at 11:06 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>>> The frv, tile and blackfin architectures are being removed, so
>>> we can clean up this header by removing all the special cases
>>> except those for ia64.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> include/uapi/asm-generic/siginfo.h | 36 ++----------------------------------
>>> 1 file changed, 2 insertions(+), 34 deletions(-)
>>>
>>
>> If I am reading siginfo.h correctly after this cleanup patch
>> we can perform another cleanup and unconditionally define
>> all of the ia64 si_codes except for __SEGV_PSTKOVF which
>> aliases SEGV_PKUERR.
>>
>> Which has the advantage that no one is tempted to define any further
>> aliased si_codes.
>
> Do you mean like this:
>
> diff --git a/include/uapi/asm-generic/siginfo.h
> b/include/uapi/asm-generic/siginfo.h
> index b2ebf16c391a..ff13ed50dde8 100644
> --- a/include/uapi/asm-generic/siginfo.h
> +++ b/include/uapi/asm-generic/siginfo.h
> @@ -186,11 +186,9 @@ typedef struct siginfo {
> #define ILL_PRVREG 6 /* privileged register */
> #define ILL_COPROC 7 /* coprocessor error */
> #define ILL_BADSTK 8 /* internal stack error */
> -#ifdef __ia64__
> -# define ILL_BADIADDR 9 /* unimplemented instruction address */
> -# define __ILL_BREAK 10 /* illegal break */
> -# define __ILL_BNDMOD 11 /* bundle-update (modification) in progress */
> -#endif
> +#define ILL_BADIADDR 9 /* unimplemented instruction address */
> +#define __ILL_BREAK 10 /* illegal break */
> +#define __ILL_BNDMOD 11 /* bundle-update (modification) in progress */
> #define NSIGILL 11
>
> /*
> @@ -204,13 +202,11 @@ typedef struct siginfo {
> #define FPE_FLTRES 6 /* floating point inexact result */
> #define FPE_FLTINV 7 /* floating point invalid operation */
> #define FPE_FLTSUB 8 /* subscript out of range */
> -#ifdef __ia64__
> -# define __FPE_DECOVF 9 /* decimal overflow */
> -# define __FPE_DECDIV 10 /* decimal division by zero */
> -# define __FPE_DECERR 11 /* packed decimal error */
> -# define __FPE_INVASC 12 /* invalid ASCII digit */
> -# define __FPE_INVDEC 13 /* invalid decimal digit */
> -#endif
> +#define __FPE_DECOVF 9 /* decimal overflow */
> +#define __FPE_DECDIV 10 /* decimal division by zero */
> +#define __FPE_DECERR 11 /* packed decimal error */
> +#define __FPE_INVASC 12 /* invalid ASCII digit */
> +#define __FPE_INVDEC 13 /* invalid decimal digit */
> #define NSIGFPE 13
>
> /*
>
> That seems reasonable. If you send me a patch with a proper
> changelog (I don't think I could explain this well enough), I'll
> add it to the series.

Yes.

I just realized you can also remove the #ifdefs for BUS_MCEERR_AR,
BUS_MCEERR_AO, and SEGV_BNDERR. As those si_codes are now always
defined. That description I expect you can handle.

For a description of the above change how does this sound?

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.

Eric

\
 
 \ /
  Last update: 2018-03-15 12:39    [W:0.067 / U:1.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site