Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Sep 2019 14:06:31 -0000
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>