From owner-svn-src-all@freebsd.org Tue Sep 3 14:06:55 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0BD87DC8EB; Tue, 3 Sep 2019 14:06:26 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N7zP3K5qz4PX3; Tue, 3 Sep 2019 14:06:25 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 7C82D1A61D; Tue, 3 Sep 2019 14:06:07 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 948BB16C01; Sun, 7 Apr 2019 16:10:49 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 528D595AB6; Sun, 7 Apr 2019 16:10:49 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 1F52616C00; Sun, 7 Apr 2019 16:10:49 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id BB1CE16BFC 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 6EA3E95AA7 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 s15so4394168qtn.3 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=Nt699h4zH5NOWPo3CUqkskqnXq6pCHfCm/LOfHus3jnf7BqVtp5K+eIPVUs5LTBudf aAMXgS8K4KbzKUrYTzZ//qk+6dXpQPoHm8sNVbMFIxsEdEGPAhhV/5VdwpkD4ptLJwrK 8QI3+bzQUx0iMKyugRHlCYkr5oTktTGDy7BuZLErywtQ87gFK9mI/+59nEFOJ/xqCG1I CdHfwoYbt03vPBIJk5R74wtcQroHwEOCdwFZEbD0ALH2jcfp/GSODIZtkFn96R0Zoh0w Vt36RTB145ehggvdrgS0VukY8CPoYG7sXBmjjuJRmyFZdkGbs2e/HBvO0sVot5TXFAsH zWAQ== X-Gm-Message-State: APjAAAVifrYIYS1FwvtuKoBsGfl4Fr2Qk5HapBJih2RzKeLSuQatNGr2 bE8uEdP2rFrmDQ4uxNcWWHfOF3GrZGmhfnnUFWLrTTJ3 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 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 Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 528D595AB6 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.967,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O 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 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: , Date: Tue, 03 Sep 2019 14:06:55 -0000 X-Original-Date: Sun, 7 Apr 2019 10:10:34 -0600 X-List-Received-Date: Tue, 03 Sep 2019 14:06:55 -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