I've got most of a stack of changes for deletion, I'll add deprecation notices and the like.

Sounds good. We should also delete them all.

Seems fine, though given we're willing to pay the cost of an exec, wrapping the thing in .if exists(${HOST_INCLUDE_ROOT}/sys/stat.h) might be tidier.

BTW, something that will need testing is to verify that the timerfd_gettime and timerfd_settime pseudo syscalls work in capability mode.

I fear I've found an issue with TFD_GETTIME32. The problem is that I believe struct itimerspec32 and struct itimerspecare the same size (but not the same layout) on non-x86 64-bit systems. As a result we need to use a different approach there. We still need to define TFD_GETTIME32 on amd64 due to the size (and thus command) difference there. I'll sketch the alternative code in the ioctl handler.

*sigh* immediately after submitting I noticed that this was a revert.

I'd personally name the functions user_timerfd_settime{,32}, but don't care that much.

In D38460#879734, @jfree wrote:

In D38460#879425, @brooks wrote:

Is the race between TFD_GETTIME and TFD_SETTIME in timerfd_settime acceptable? I wonder if TFD_SETFLAGS should be _IOWR and always return the previous value.

Will execution continue in userspace before the kernel returns at timerfd.c:56? I'm not completely clear on how synchronicity works in the kernel for situations like this. I assumed the userspace thread would wait for the kernel to return before continuing execution. I don't see a reason for TFD_SETFLAGS to read the current flags considering Linux doesn't support similar functionality. Are you suggesting this to check for TFD_GETTIME completion?

Is the race between TFD_GETTIME and TFD_SETTIME in timerfd_settime acceptable? I wonder if TFD_SETFLAGS should be _IOWR and always return the previous value.

Seems fine.

In D38561#877328, @jhb wrote:

I know there is also some stuff in ports/Mk for things like CROSS_TOOLCHAIN, etc. That is potentially useful for other cross-building setups though, but I'm not sure if there any other base/ specific bits in other parts of the tree? (Also, if we do want to remove CROSS_TOOLCHAIN and friends from Mk/, I'd rather @bapt or someone else more experienced in Mk/ handle that.)

Here's a rough outline of the changes for 32-bit compat. Untested in any way, but hopefully points in the right direction.

In D38459#875880, @kib wrote:

I suggest to add ioctl's to perform the ops on the descriptor, instead of filling the syscall table with more one-purpose entries.

BTW, just to be clear, I'm really happy to see this work. It's a portability gap that has caused issues for multiple users of Morello and CheriBSD so I'm looking forward to seeing it landed.

In D38459#875687, @jfree wrote:

Also, should I move all 3 syscalls (timerfd_create, timerfd_settime, timerfd_gettime) to standard syscalls? Or should I keep timerfd_create inside __specialfd? I'm not exactly clear on the purpose of __specialfd at this point.

The overall interface has ABI compatibility issues.

Might as well commit this before removal. It's unlikely anyone will ever use this (the IP block is weird), but that would make it slightly easier to restore if someone did.

I generally like the text and @imp has included my feedback from prior versions.

I'd somewhat like to see the compat bits go under COMPAT_FREEBSD13, probably along with O[GP]IO_KEYMAP, but that can go in another commit and there are arguments against it since people do tend to get bitten by not including COMPAT_* options in their custom kernels.

I'd be tempted to allow 0 so it could be used for standard syscall-like functions, but this is fine.

I did find myself wondering if host_to_stand_errno should assert that e <= 0 since it's a relatively common error to accidentally use positive errors when modifying linux code.

It was mentioned on IRC that one reason to keep this is to reduce FS size. IMO if you're at the point wehre this makes a meaningful difference it's time to switch from a subtractive image creation process to an additive one.

In D38029#863849, @markj wrote:

To trigger the problem, a test case might do something like

./root/.ssh type=dir
./root/.ssh/id_ed25519 type=file contents=/path/to/key

where ./root/.ssh doesn't exist?

• Simplify fs_open_can_fail

• Avoid signed vs unsigned comparison issues