From owner-svn-src-all@freebsd.org Sun Apr 7 16:10:47 2019 Return-Path: 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 ; 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 ; 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 ; 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: <201904071510.x37FA7tm050626@gndrsh.dnsmgr.net> <201904071535.x37FZ7bk073860@slippy.cwsent.com> In-Reply-To: <201904071535.x37FZ7bk073860@slippy.cwsent.com> From: Warner Losh Date: Sun, 7 Apr 2019 10:10:34 -0600 Message-ID: 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 Cc: "Rodney W. Grimes" , Shawn Webb , Mariusz Zaborski , src-committers , svn-src-all , svn-src-head 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" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 16:10:47 -0000 On Sun, Apr 7, 2019 at 9:35 AM Cy Schubert 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