Re: RFC: ENOSYS vs SIGSYS for FreeBSD ABIs

On Mon, Apr 20, 2026 at 08:36:01PM +0200, Robert Clausecker wrote:
> Hi Konstantin,
> 
> Am Mon, Apr 20, 2026 at 08:34:07PM +0300 schrieb Konstantin Belousov:
> > On Mon, Apr 20, 2026 at 08:03:22AM +0000, Brooks Davis wrote:
> > > As a developer I've never found SIGSYS helpful.  That being said, I
> > > don't think a more nuanced approach would be all that hard.  One option
> > > I've pondered would to automatially flip kern.signosys to 0 (and
> > > probably kern.lognosys to > 0) if init gets a SIGSYS (maybe limited to
> > > before it forks successfully).  You'd probably want some pretty shouty
> > > logging to go with that, but it would let you survive a kernel roll-back
> > > with new syscalls in csu code.
> > 
> > I think by 'csu' you mean 'all code executed before main()'.
> > crt1.o is now very minimal, the real startup work is delegated to libc.
> > 
> > I think it is time to switch init to be dynamically linked.
> > At least this would make the job of fixing userspace (instead of kernel)
> > to be limited to rtld+libc, instead of rtld+libc+init.
> 
> A dynamically linked init means that if anything goes wrong with shared
> library support, init doesn't get up and you end up with a nonbooting
> system.  Is this really a good idea?

If rtld or libsys or libc or or libtinfo or libedit or bin/sh are broken
you get the unbootable system as well.  The fact that kernel booted does
not help if userspace is blocked.

See D56536.