Re: RFC: ENOSYS vs SIGSYS for FreeBSD ABIs

On Mon, 20 Apr 2026 at 03:17, Brooks Davis <[email protected]> wrote:
>
> On Mon, Apr 20, 2026 at 08:37:05AM +0000, Poul-Henning Kamp wrote:
> > --------
> > Brooks Davis writes:
> >
> > > [???] but it would let you survive a kernel roll-back
> > > with new syscalls in csu code.
> >
> > I would expect precisely that to be the situation were we would
> > be careful to handle that scenario :-)
>
> You can if you use an out of band mechanism to detect the presence
> of the syscall by checking __getosreldate, but that works base in
> unmodified FreeBSD.  Downstream you may need an alternative mechanism
> like checking a feature sysctl.
>
> My frustration with SIGSYS is that it's an annoyance for developers and
> requires special handling to avoid too many user complaints.  We then
> forget to clean up the special handling once it's obsolete (which takes
> years due to our de facto src upgrade support model).

How much foot-shoot-gun are we really able to do here?

I can imagine scenarios where some later non-advisory security syscall
doesn't exist
or isn't compiled into the kernel, you run your binary, the call
fails, and then subsequent
code just continues running. The implicit contract between userland
author and kernel
right now is "I make a call, it succeeds, fails or is interrupted" and
although I know
of plenty of places (some due to me) where the return value of
syscalls aren't checked,
I can't imagine it'll get ... "better" with this.

I'd be a little less worried about it if we had a way to express "I'm
handling the error
from this syscall" in a way that let the kernel know we were either
happy with the default
signal handler or not. (This kind of mirrors what I've seen various
Android APIs do -
default exceptions if you don't explicitly handle the return value.)



-adrian