Re: git: c29cba408d19 - main - stand: Narrow the 'signal emulation' we provide

On Tue, Nov 19, 2024, 8:56 PM Jessica Clarke <jrtc27@freebsd.org> wrote:

> On 20 Nov 2024, at 03:35, Warner Losh <imp@FreeBSD.org> wrote:
> >
> > The branch main has been updated by imp:
> >
> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=c29cba408d197ed2c267d0605e4225bb54153e01
> >
> > commit c29cba408d197ed2c267d0605e4225bb54153e01
> > Author:     Warner Losh <imp@FreeBSD.org>
> > AuthorDate: 2024-11-20 03:05:11 +0000
> > Commit:     Warner Losh <imp@FreeBSD.org>
> > CommitDate: 2024-11-20 03:24:41 +0000
> >
> >    stand: Narrow the 'signal emulation' we provide
> >
> >    We only need to provide sig_atomic_t in emulation. However, including
> >    machine/signal.h brings in too much namespace pollution related to
> >    signals. Instead, define sig_atomic_t as long. Setting long is async
> >    atomic on all platforms (though powerpc64 defines it to an int),
> though
> >    that doesn't matter since the boot loader doesn't use signals.
> >
> >    Sponsored by:           Netflix
> > ---
> > stand/libsa/stand.h | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/stand/libsa/stand.h b/stand/libsa/stand.h
> > index 260defa3a33d..e1188fb73a26 100644
> > --- a/stand/libsa/stand.h
> > +++ b/stand/libsa/stand.h
> > @@ -82,8 +82,13 @@
> > #define EOFFSET (ELAST+8) /* relative seek not supported */
> > #define ESALAST (ELAST+8) /* */
> >
> > -/* Partial signal emulation for sig_atomic_t */
> > -#include <machine/signal.h>
> > +/*
> > + * LUA needs sig_atomic_t. This is defined to be long or int on all our
> > + * platforms. On all but powerpc, these are all the same thing as long.
> 64-bit
> > + * powerpc defines this as int, but long can also be accessed
> atomically. It's
> > + * also OK because we don't have signal handlers in the boot loader.
> > + */
>
> Presumably an oversight when adding the powerpc64* ports :( Probably we
> should fix this by taking advantage of being able to break ABI for tier
> 2 architectures between major versions. Shame it wasn’t done the same
> time as ELFv1 -> ELFv2. We fixed riscv and arm64’s SIG_ATOMIC_MIN/MAX
> recently, but the underlying types were still long in that case,
> thankfully.
>

Likely. But i already have too much on my plate. Just a weird thing i
noticed.

Warner

Jess
>
> > +typedef long sig_atomic_t;
> >
> > __BEGIN_DECLS
> >
>
>