From owner-svn-src-all@freebsd.org Sun Apr 7 16:10:47 2019
Return-Path: <owner-svn-src-all@freebsd.org>
Delivered-To: svn-src-all@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D20811563214
for <svn-src-all@mailman.ysv.freebsd.org>;
Sun, 7 Apr 2019 16:10:46 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com
[IPv6:2607:f8b0:4864:20::835])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 6D26C95AA6
for <svn-src-all@freebsd.org>; Sun, 7 Apr 2019 16:10:46 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: by mail-qt1-x835.google.com with SMTP id x12so12734251qts.7
for <svn-src-all@freebsd.org>; Sun, 07 Apr 2019 09:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bsdimp-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=6C15y/EwF8qjdlIzpTk8WM25tFfyF7RydrDG/QHuW4E=;
b=guXqcWnfUsBcCnUDnEZ+gdzlMuUui/8LS9qB5Bf3pMXRXmoJoPZvC3hPNHLqBzu/9Z
//sCRTpDB/C6hHnCo1DTUY/LowFmsGjS5wpAjlENKPUjqbYRj3eI6mWxwi6lFVx8wBqK
rsuT3PxvRPhRpBIo5TbjEP03ozKyapVbNecYKRjr+xBnQWj/toAFU3M5HoxudkZnqShf
W5URaq6fTR9Jc9tgOUrP+kq9bcGNa9Ne5GJJDzN630QFR/8nt0o9Ertlf/mA2b9nhMyX
zy4QVgAu4lrmlx/ABUntkUUQaYmHE8IcSDa0XbXl6S0vZ9b6lN5LZSaWhtTD7MPBmkq0
O4dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=6C15y/EwF8qjdlIzpTk8WM25tFfyF7RydrDG/QHuW4E=;
b=tK+uK7XlahklXpUAjyBUl1BwScPrgP6wM/Xu23TouAScFy5+jakiFZT3taY5wRAAa7
mWbVYNX4dil1WjSpWTQmSv6Ud4/JZ/NBG2KpYQxck+xo1wkR/7rnlzJf9Ov0s11WjQu0
VTL0BT/OhjX09eu0P3dqEoOxBhJdJH7q+cTmen7RmlXUw67y/Be8ng/RZA84465YBYY5
znFQM0AGFCi6ExNTFnm7aOCjs/9YfRNESwThZzg7zHrMBO8itb98e9aS6NSX3xcaU77L
vL6tRiTahBteEw4F3lgxmjYJXyw/OfzAz4nlZVT72cdnN8nHUspIHR0+QQ1n0AkaxlzO
WhkQ==
X-Gm-Message-State: APjAAAXLtvK1At0K17L8JqNC2Q9np44jbyjlrx4UrSno7CwnKl+QH0ZX
dyiIoh/zv50RX7IuyG8A/K3tHMVoOYuH6NUV8xizew==
X-Google-Smtp-Source: APXvYqyoYa3wYbmqt5Wnxtxtk1NUVaLxe2VS5+mURa6Sf6HC70Pxnz/8Evmhf0qD1marEfb+XrZOYdrkI67QqDK//G8=
X-Received: by 2002:a0c:9922:: with SMTP id h31mr19336547qvd.137.1554653445352;
Sun, 07 Apr 2019 09:10:45 -0700 (PDT)
MIME-Version: 1.0
References: <freebsd@gndrsh.dnsmgr.net>
<201904071510.x37FA7tm050626@gndrsh.dnsmgr.net>
<201904071535.x37FZ7bk073860@slippy.cwsent.com>
In-Reply-To: <201904071535.x37FZ7bk073860@slippy.cwsent.com>
From: Warner Losh <imp@bsdimp.com>
Date: Sun, 7 Apr 2019 10:10:34 -0600
Message-ID: <CANCZdfrr6-s+h-6k5bSA_QDe-9GSoGnZjpJEKBZV0sQ5_xzD=A@mail.gmail.com>
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
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>
X-Rspamd-Queue-Id: 6D26C95AA6
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org
X-Spamd-Result: default: False [-6.97 / 15.00];
NEURAL_HAM_MEDIUM(-1.00)[-1.000,0];
NEURAL_HAM_SHORT(-0.97)[-0.975,0]; REPLY(-4.00)[];
NEURAL_HAM_LONG(-1.00)[-1.000,0]
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "SVN commit messages for the entire src tree \(except for "
user" and " projects" \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>,
<mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>,
<mailto:svn-src-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Apr 2019 16:10:47 -0000
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