Due to D41976

In D41859#955406, @kib wrote:

In D41859#955405, @dchagin wrote:

In D41859#955376, @kib wrote:

In D41859#955367, @dchagin wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

yes, OBSOL syscalls, https://people.freebsd.org/~dchagin/nosys.c

And ABSENT as well?

In D41859#955405, @dchagin wrote:

In D41859#955376, @kib wrote:

In D41859#955367, @dchagin wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

yes, OBSOL syscalls, https://people.freebsd.org/~dchagin/nosys.c

And ABSENT as well?

In D41859#955376, @kib wrote:

In D41859#955367, @dchagin wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

In D41859#955367, @dchagin wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

In D41859#955044, @kib wrote:

D41901 sounds as a hack, again.

Am I right that the issue is that nosys() sends signal, while Linux' nosys should not? If yes, there are two options:

yes

D41901 sounds as a hack, again.

In D41859#954114, @kib wrote:

Can you explain more? Does linuxolator need syscall slot 0?

Can you explain more? Does linuxolator need syscall slot 0?

In D38459#950118, @jfree wrote:

This patch has been applied to src under commit af93fea710385b2b11f0cabd377e7ed6f3d97c34.

There doesn't seem to be a way to associate this review directly with that commit, so I'm just going to abandon it.

This patch has been applied to src under commit af93fea710385b2b11f0cabd377e7ed6f3d97c34.

In D38459#947334, @imp wrote:

Are there any tests?

I have this staged and plan to commit once I confirm universe builds.

hmm, looks like the problem in how protections handled during stack grows

debootstrap for Ubuntu 23.04 requires Linux ionice command which depends on these syscalls

I would like to get this patch committed before the 14.0 freeze in August. I am personally in favor of making these syscalls, but I'd like some notice if we're not going this route.

Add brief comments explaining each of the tfd_jumped macros.

whoops, magic2 type changed to uint32_t too

Yes, done, it's much better now, thank you!