Re: [PATCH v2 4/4] tools/nolibc: add signal support

[Willy Tarreau <w@1wt.eu>]

On Sun, Jul 13, 2025 at 05:02:27PM +0200, Thomas Weißschuh wrote:
> On 2025-07-11 09:25:26+0200, Benjamin Berg wrote:
> > On Fri, 2025-07-11 at 07:40 +0200, Thomas Weißschuh wrote:
> > > On 2025-07-10 12:39:50+0200, Benjamin Berg wrote:
> > > > From: Benjamin Berg <benjamin.berg@intel.com>
> > > > 
> > > > Add support for sigaction() and implement the normal sa_mask helpers.
> > > > 
> > > > On many architectures, linux/signal.h pulls in compatibility
> > > > definitions
> > > > for the old sigaction syscall instead of rt_sigaction. However, the
> > > > kernel can be compiled without support for this compatibility
> > > > syscall
> > > > and it also results in sa_mask to be too small for realtime
> > > > signals.
> > > > 
> > > > To work around this, the includes are handled separately for each
> > > > architecture. This way either linux/signal.h or the asm-generic
> > > > headers
> > > > can be used to get the correct definition for the rt_sigaction
> > > > syscall
> > > > including sigset_t.
> > > 
> > > I checked this against my WIP alpha support and there this scheme
> > > breaks. linux/signal.h provides the old compat types but
> > > the asm-generic variant provides an incorrect SIGCHLD.
> > > 
> > > Any ideas?
> > 
> > I had a quick look, and I don't have a good idea really. For sparc
> > there was at least a #define that permitted to get the correct version.
> > But here, there is nothing.
> > 
> > Probably the best is to just copy in a modified version of signal.h
> > with the correct definitions present. i.e. replace the "ifndef
> > __KERNEL__" sections with something reasonable.
> 
> But then we can just have our own copy for every architecture, no?
> To me that looks like the best solution right now.

I generally agree. Originally in nolibc, lots of stuff was copied and
we only used very little of UAPI. As new architectures were supported,
we took this opportunity for cleaning this up and relying more on UAPI,
but that doesn't mean we need to get rid of our local definitions all
the time, so if that helps, yeah clearly we can have our local copies
and definitions.

Cheers,
Willy