Date: Thu, 24 Aug 2023 13:29:06 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: Jessica Clarke <jrtc27@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: 4a69fc16a583 - main - Add membarrier(2) Message-ID: <CANCZdfq7y2RxtMNF7stt1hSbwqEWsia3muy4nT0oqwaCOv=maA@mail.gmail.com> In-Reply-To: <747e34d5-8191-5fb9-deb4-c94d7f1693e0@FreeBSD.org> References: <202308230007.37N07cOK082906@gitrepo.freebsd.org> <748B7A01-5011-44EE-BB04-282AE96F9B5B@freebsd.org> <ZOVxDqInEgUhBaIN@kib.kiev.ua> <0F3EA94D-6696-471C-ABF6-840B5E92967F@freebsd.org> <CANCZdfpqJM4dsyEFJt6P_Yf9WBJ9V3hYe8tVCipJr0pecsHekg@mail.gmail.com> <747e34d5-8191-5fb9-deb4-c94d7f1693e0@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Thu, Aug 24, 2023 at 10:19 AM John Baldwin <jhb@freebsd.org> wrote: > On 8/23/23 6:01 AM, Warner Losh wrote: > > On Tue, Aug 22, 2023 at 11:37 PM Jessica Clarke <jrtc27@freebsd.org> > 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 [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 24, 2023 at 10:19 AM John Baldwin <<a href="mailto:jhb@freebsd.org">jhb@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/23/23 6:01 AM, Warner Losh wrote:<br> > On Tue, Aug 22, 2023 at 11:37 PM Jessica Clarke <<a href="mailto:jrtc27@freebsd.org" target="_blank">jrtc27@freebsd.org</a>> wrote:<br> > <br> >><br> >>> The addition does not change any existing code path in the kernel.<br> >><br> >> No, but it commits us to a new syscall being stable just days before 14<br> >> branches and has its ABI frozen.<br> >><br> > <br> > I'd planned on committing timerfd later today. I didn't consider it an ABI<br> > breakage, since it was just additive. It's one of the things that can be<br> > MFC'd (we don't prohibit new system calls).<br> <br> (Not taking a side on the merits of the current membarrier(2) implementation)<br> <br> I think Jess's point here is not that a new syscall is not a valid ABI<br> breakage, but more that once you add a new syscall that makes it into a<br> release, now the ABI of that syscall is frozen and can't be changed. That<br> said, syscall numbers are relatively "cheap", so if we had to renumber<br> membarrier(2) because its ABI was found to be a problem that could be done,<br> albeit at the cost of keeping the old one around under COMPAT_FREEBSD<n>.<br></blockquote><div><br></div><div>OK. I jumped to the wrong conclusion... Good points all around.</div><div><br></div><div><br></div><div>Warner</div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq7y2RxtMNF7stt1hSbwqEWsia3muy4nT0oqwaCOv=maA>