Re: RFC: ENOSYS vs SIGSYS for FreeBSD ABIs

On 20 Apr 2026, at 19:47, Konstantin Belousov <[email protected]> =
wrote:
>=20
> On Mon, Apr 20, 2026 at 08:36:01PM +0200, Robert Clausecker wrote:
>> Hi Konstantin,
>>=20
>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> 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?
>=20
> 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.
>=20
> See D56536.

Well, technically init could drop to single user mode where you can
spawn /rescue/sh if you want to, but you=E2=80=99ll probably soon find =
the
things you need to do to recover the system require something
dynamically-linked that=E2=80=99s not got a rescue variant.

Jessica