On 8/23/23 6:01 AM, Warner Losh wrote:
On Tue, Aug 22, 2023 at 11:37 PM Jessica Clarke <[email protected]> wrote:
The addition does not change any existing code path in the kernel.
No, but it commits us to a new syscall being stable just days before 14
branches and has its ABI frozen.
I'd planned on committing timerfd later today. I didn't consider it an ABI
breakage, since it was just additive. It's one of the things that can be
MFC'd (we don't prohibit new system calls).
(Not taking a side on the merits of the current membarrier(2) implementation)
I think Jess's point here is not that a new syscall is not a valid ABI
breakage, but more that once you add a new syscall that makes it into a
release, now the ABI of that syscall is frozen and can't be changed. That
said, syscall numbers are relatively "cheap", so if we had to renumber
membarrier(2) because its ABI was found to be a problem that could be done,
albeit at the cost of keeping the old one around under COMPAT_FREEBSD<n>.
--
John Baldwin
