Date: Sun, 7 Apr 2019 10:10:34 -0600 From: Warner Losh <imp@bsdimp.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Shawn Webb <shawn.webb@hardenedbsd.org>, Mariusz Zaborski <oshogbo@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs Message-ID: <CANCZdfrr6-s%2Bh-6k5bSA_QDe-9GSoGnZjpJEKBZV0sQ5_xzD=A@mail.gmail.com> In-Reply-To: <201904071535.x37FZ7bk073860@slippy.cwsent.com> References: <freebsd@gndrsh.dnsmgr.net> <201904071510.x37FA7tm050626@gndrsh.dnsmgr.net> <201904071535.x37FZ7bk073860@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 7, 2019 at 9:35 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote: > In message <201904071510.x37FA7tm050626@gndrsh.dnsmgr.net>, "Rodney W. > Grimes" > writes: > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb < > shawn.webb@hardenedbsd.org> wr > > ote: > > > >On Sat, Apr 06, 2019 at 09:34:26AM +0000, Mariusz Zaborski wrote: > > > >> Author: oshogbo > > > >> Date: Sat Apr 6 09:34:26 2019 > > > >> New Revision: 345982 > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982 > > > >> > > > >> Log: > > > >> Introduce funlinkat syscall that always us to check if we are > > > >removing > > > >> the file associated with the given file descriptor. > > > >> > > > >> Reviewed by: kib, asomers > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous > version) > > > >> Discussed with: pjd, and many others > > > >> Differential Revision: https://reviews.freebsd.org/D14567 > > > > > > > >Hey Mariusz, > > > > > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls? > > > >I can't remember off-hand. > > > > > > > >Thanks, > > > > > > I don't think so. Why force the rebuild of all ports through poudriere > over > > something that would never affect any of them? > > > > So that you can if version >= foo to know it is safe to use the new > syscal? > > Or if version < foo you must use the old way. > > Granted. However we do need something to avoid gratuitous rebuilds of > ports. > > Personally, my poudriere script adjusts the pkg version > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with > that of the jail version (reported by poudriere jail -i -j $JAIL), > rebuilding all ports when I (the human) determines when the machine > should rebuild all ports with -c. > > In that regard FreeBSD version bumps occasionally seem a little > gratuitous. Using the same indicator to tell whether software should be > able to use a new feature and when ports build infrastructure should > summarily delete all packages forcing a rebuild of absolutely > everything is probably not the best. > > Just throwing out an idea, what if poudriere considers the first N > bytes of __FreeBSD_version significant? Having said that, looking at > __FreeBSD_version, I don't think we have enough digits to do what I was > planning on suggesting. But, you get the idea of what I'm driving at. > Maybe a new macro such as __FreeBSD_ports that is incremented every > time a change that affects ports? > > Anyhow, I'm not too terribly concerned as what I have (selfishly > speaking) works. But we may as a group might want to consider this at > some point to build some efficiency into the ports part of the equation. > We generally bump the version around the time we add a syscall. This allows any wrappers to call it or not based on the kernel version and avoid a SIGSYS when we're doing forward compatibility hacks for whatever reason. The current overloading of __FreeBSD_version is unfortunate. We've been quite liberal over the past 2 decades at bumping it because it's free to do so. Or so the thinking has been. I personally think we should continue to do so, but maybe look at piggy-backing those changes we can if someone else bumped it in the last few days. To give some perspective, in the ~120 days since we branched, we've bumped it 17 times. This is more or less weekly, which suggests we don't have a problem that we need to optimize too much here. If Poudriere wants to optimize building, I'd suggest that you have a command line argument / config file thing that sets the maximum skew. Normally, you could set it up to be pretty tolerant, but if you knew something was a big deal, you could then crank down to intolerant. The current setting of '1' for this skew should be the default. I'm not sure a FreeBSD_ports would scale. How do you know a port won't need to know about the new syscall? It's from Linux, and there may be some ports that use it if available. As a src committer, I've not easy way to know (and no hard way to know that's not a full exprun). Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrr6-s%2Bh-6k5bSA_QDe-9GSoGnZjpJEKBZV0sQ5_xzD=A>