Is it reasonable to provide the inline versions of these methods for complicated cases, like x86? Could it be always a function call?

This should be reviewed by kib, andy (for ARM), jrtc27 (for riscv64), jhibbits (for ppc), and kargl (for msun).

In D59277#1360135, @ngie wrote:

I think the prior approach suggested by @dim to make as minimal of a change as possible makes a lot of sense: there's no real single-maintainer in inetd and the daemon has remained in maintenance mode for many years.

This didn't apply cleanly on :main for me -- I think it needs to be rebased.

Approved by: ngie (co-mentor)

revert refactoring

Added FAULT_TRAN_L1.

Also catch FAULT_TRAN_L1.

Was introduced in commit rG:e548a1d4c8cce0f67b82d6d5387847c7551de6c4

Note that these are currently accessed in libexec/rc/rc.d/linux:

This should be reviewed by kib, andy (for ARM), jrtc27 (for riscv64), jhibbits (for ppc), and kargl (for msun). Please contact kargl by e-mail, he does not have a phabricator account.

Address feedback by ngie@

@aokblast there is also PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297155 now referencing some of these problems.

I think the prior approach suggested by @dim to make as minimal of a change as possible makes a lot of sense: there's no real single-maintainer in inetd and the daemon has remained in maintenance mode for many years.

I'm not sure if this is the right approach because if_detach_internal() is not the only consumer of if_delgroup. But since we're using ck_queue here, I think it should be fine.
I prefer to have other opinions on this change as well.

In D55687#1356375, @aokblast wrote:

@bapt Hi, My version has been merged by @emaste. Could you please close this?