> There are times when this doesn't work. Syscall resumption and cancellation come to mind. Also, __kernel_vsyscall is a hack to make fast syscalls work on the awful 32-bit x86 architecture, not a nice feature.
It's a pretty nice feature in the context of being able to make compatibility layers on other OS'ses in userspace which was the discussion here. Or would be if it was always used. Why doesn't it work for syscall resumption and cancellation?
> There is no __kernel_vsyscall or similar feature on x86_64.
Yes that was exactly what I was complaining about.
> You can on Linux using seccomp.
Yes but why would I want to make a linux compatibility layer on linux?
> It's a pretty nice feature in the context of being able to make compatibility layers on other OS'ses in userspace which was the discussion here. Or would be if it was always used. Why doesn't it work for syscall resumption and cancellation?
For resumption, a signal that interrupts a resumable syscall points RIP to an explicit int 80 instruction in the vDSO. This behavior would be a bit unfriendly to emulate.
For cancellation, the only good implementation of cancellation that I'm aware of (musl's) relies on syscalls being an actual atomic instruction so that a signal handler can tell whether a syscall actually happened. __kernel_vsyscall is an opaque function and can't be used like this.
> Yes but why would I want to make a linux compatibility layer on linux?
For sandboxing? For experimentation? Or how about to make a compatibility layer emulating something else that runs on Linux?
It's a pretty nice feature in the context of being able to make compatibility layers on other OS'ses in userspace which was the discussion here. Or would be if it was always used. Why doesn't it work for syscall resumption and cancellation?
> There is no __kernel_vsyscall or similar feature on x86_64.
Yes that was exactly what I was complaining about.
> You can on Linux using seccomp.
Yes but why would I want to make a linux compatibility layer on linux?