Re: ARC vs. generic sigaction (was Re: [PATCH 08/21] ARC: Linux Syscall Interface)

[Arnd Bergmann <arnd@arndb.de>]

On Thu, Dec 20, 2018 at 12:19 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 19/12/2018 20:23, Vineet Gupta wrote:
> > On 12/19/18 2:00 PM, Adhemerval Zanella wrote:
> >> One possibility is to define an arch-specific __sigset_t.h with a custom
> >> _SIGSET_NWORDS value and add an optimization on Linux sigaction.c to check
> >> if both kernel_sigaction and glibc sigaction share same size and internal
> >> layout to use the struct as-is for syscall instead of copy to a temporary
> >> value (similar to what we used to have on getdents).  ARC would still have
> >> arch-specific code and would be the only ABI to have a different sigset_t
> >> though.
> >
> > I don't like ARC to single out either. But as Joseph suggests could this be
> > starting point for arches of future. Assuming it does, would rather see this or
> > the approach Joseph alluded to earlier [1]
> >
> > [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-December/005122.html
> >
> >>
> >> However I *hardly* think sigaction is a hotspot in real world cases, usually
> >> the signal action is defined once or in a very limited number of times.  I am
> >> not considering synthetic benchmarks, specially lmbench which in most cases
> >> does not measure any useful metric.
> >
> > I tend to disagree. Coming from embedded linux background, I've found it immensely
> > useful to compare 2 minimal systems: especially when distos, out-of-box packages,
> > fancy benchmarks don't even exist.
> >
> > At any rate, my disagreement with status quo is not so much of optimize for ARC,
> > but rather pointless spending of electrons. When we know that there are 64 signals
> > at max, which need 64-bits, why bother shuffling around 1k bits, specially when
> > one is starting afresh and there's no legacy crap getting in the way.
> >
> > The case of adding more signals in future is indeed theoretically possible but
> > that will be an ABI change anyways.
>
> The only advantage of using a larger sigset_t from glibc standpoint is if
> kernel ever change it maximum number of supported signals it would not be
> a ABI change (it would be if glibc provided sigset_t need to be extended).
>
> My point was that this change would hardly help in performance or memory
> utilization due the signal set common utilization in exported and internal
> API.  But at the same time the signal set hasn't been changed for a *long* time
> and I don't see indication that it will any time soon. So a new architecture
> might indeed assume it won't change and set its default to follow Linux user
> ABI.

I just checked again what we actually use in the kernel.
With very few exceptions, all architectures in current kernels use

#define _NSIG             64
#define _NSIG_WORDS       (_NSIG / _NSIG_BPW)
typedef struct {
    /* this sucks for big-endian 32-bit compat mode */
    unsigned long sig[_NSIG_WORDS];
} sigset_t;

The only two exceptions I see are:

- alpha uses a scalar 'unsigned long' instead of the struct+array, but
  the effect is the same layout.
- For unknown reasons, all three MIPS ABIs now use _NSIG=128.
  This changed during linux-2.1.x from 65, to 32 and then the current
  value...

All users of sigset_t that I could find in the kernel just check
the size argument to ensure it matches _NSIG, and return
EINVAL otherwise.

      Arnd