Due to D41976
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 25 2023
Sep 21 2023
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?
Sep 20 2023
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?
Sep 19 2023
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
Sep 18 2023
D41901 sounds as a hack, again.
In D41859#954114, @kib wrote:Can you explain more? Does linuxolator need syscall slot 0?
Sep 14 2023
Can you explain more? Does linuxolator need syscall slot 0?
Sep 1 2023
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.
Aug 24 2023
In D38459#947334, @imp wrote:Are there any tests?
I have this staged and plan to commit once I confirm universe builds.
Aug 17 2023
Aug 4 2023
Jul 29 2023
Jul 28 2023
Jul 24 2023
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
Jul 22 2023
Jul 18 2023
Jun 29 2023
Jun 28 2023
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.
Jun 8 2023
whoops, magic2 type changed to uint32_t too
Yes, done, it's much better now, thank you!
Jun 7 2023
Don't leak xfpustate if copyin of magic2 failed
Rebase to D40443
Done, thank you!
Jun 6 2023
ugh, old commit, fix magic2 printout in error and some comments
May 31 2023
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?
May 30 2023
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.
May 29 2023
May 28 2023
May 26 2023
May 24 2023
May 22 2023
- 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?
May 21 2023
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.