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!

Don't leak xfpustate if copyin of magic2 failed

Rebase to D40443

Done, thank you!

ugh, old commit, fix magic2 printout in error and some comments

In D38459#918469, @kib wrote:

In D38459#918467, @imp wrote:

I have code that automatically translates new system calls between host/target for bsd-user (though I'm not quite ready to commit it).
ioctl is possible, but has a lot more exceptional cases so is harder to do automatically. There's no automated annotation like there is for system calls.
The 'generic interfaces' require that I go and create annotations for each of the 'op codes' in that, because that doesn't exist in our current annotation.

So having a few extra system calls means they will be annotated and my job of getting it to work in bsd-user and others wanting to do automatic translation is easier.

For system calls you do need annotations, you cannot properly understand the purpose of any pointer passed to syscall otherwise. Is it in, out, in/out, or even just an abstract address like mmap/munmap/madvise arguments?

For system calls you do need annotations, you cannot properly understand the purpose of any pointer passed to syscall otherwise. Is it in, out, in/out, or even just an abstract address like mmap/munmap/madvise arguments?

For ioctls, the meaning of the command/arg is quite formalized, at least in BSDs. You are well aware that we encode both sizes and directions for copyin and copyout. After I took some time thinking how to implement what you described, I was surprised by the statement that syscalls are easier than ioctls.

That said, I am quite dislike extending the syscall semantical coverage by adding one-off operations. In the case of special fds, having all ops grouped together (under ioctl umbrella) localizes the interfaces and make them more comprehensive. This is, of course, my opinion, but all my experience supports the claim.

In D38459#918467, @imp wrote:

I have code that automatically translates new system calls between host/target for bsd-user (though I'm not quite ready to commit it).
ioctl is possible, but has a lot more exceptional cases so is harder to do automatically. There's no automated annotation like there is for system calls.
The 'generic interfaces' require that I go and create annotations for each of the 'op codes' in that, because that doesn't exist in our current annotation.

So having a few extra system calls means they will be annotated and my job of getting it to work in bsd-user and others wanting to do automatic translation is easier.

I have code that automatically translates new system calls between host/target for bsd-user (though I'm not quite ready to commit it).
ioctl is possible, but has a lot more exceptional cases so is harder to do automatically. There's no automated annotation like there is for system calls.
The 'generic interfaces' require that I go and create annotations for each of the 'op codes' in that, because that doesn't exist in our current annotation.

• tfd_jumped must be set to TFD_CANCELED, not TFD_JUMPED, for timerfd_settime to return ECANCELED.
• style(9) line-break fixes courtesy of @mckusick.

Er? Can you explain? What is confusing for ioctl, and what is intuitive for the syscall interface?

In D38459#914966, @jfree wrote:

Why? I do not like it very much. It is not as if all (or most) other individual kernel ops where performed by dedicated syscall entries, so I do not see a good reason to do it there. Ioctl perfectly fits the intent of providing file-specific requests.

The system call interface is standard and more intuitive for those that want to extend timerfd later.
The ioctl() implementation is confusing and messy for compat.

Er? Can you explain? What is confusing for ioctl, and what is intuitive for the syscall interface?

Why? I do not like it very much. It is not as if all (or most) other individual kernel ops where performed by dedicated syscall entries, so I do not see a good reason to do it there. Ioctl perfectly fits the intent of providing file-specific requests.

In D38459#914918, @jfree wrote:

• Support TFD_TIMER_CANCEL_ON_SET settime flag using timerfd_jumped().
• Convert ioctl() interface to native syscalls.

• Support TFD_TIMER_CANCEL_ON_SET settime flag using timerfd_jumped().
• Convert ioctl() interface to native syscalls.