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

Warner Losh imp at bsdimp.com
Sun Apr 7 16:10:47 UTC 2019


On Sun, Apr 7, 2019 at 9:35 AM Cy Schubert <Cy.Schubert at cschubert.com>
wrote:

> In message <201904071510.x37FA7tm050626 at gndrsh.dnsmgr.net>, "Rodney W.
> Grimes"
> writes:
> > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb <
> shawn.webb at 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


More information about the svn-src-head mailing list