On Thu, Aug 24, 2023 at 10:19 AM John Baldwin <[email protected]> wrote:
> 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>. > OK. I jumped to the wrong conclusion... Good points all around. Warner
