From owner-svn-src-head@freebsd.org Tue Sep 3 14:06:31 2019 Return-Path: Delivered-To: svn-src-head@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 7EF23DC919; 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 46N7zP4MLSz4PX8; Tue, 3 Sep 2019 14:06:25 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 8F37F1A635; 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 8C59217DFF; Sun, 7 Apr 2019 16:52:48 +0000 (UTC) (envelope-from owner-src-committers@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 3494D97BF8; Sun, 7 Apr 2019 16:52:48 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 1A6C117DFE; Sun, 7 Apr 2019 16:52:48 +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 20B9E17DFA; Sun, 7 Apr 2019 16:52:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CC8497BF5; Sun, 7 Apr 2019 16:52:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id DB26hu2mYo7SQDB27hSY0o; Sun, 07 Apr 2019 10:52:41 -0600 X-Authority-Analysis: v=2.3 cv=Go88BX9C c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=oexKYjalfGEA:10 a=xfDLHkLGAAAA:8 a=YxBL1-UpAAAA:8 a=iKhvJSA4AAAA:8 a=ypVJL4-jAAAA:8 a=6I5d2MoRAAAA:8 a=FeRXxS_nJQ1RsfFfj7UA:9 a=CjuIK1q_8ugA:10 a=IfaqVvZgccqrtc8gcwf2:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=odh9cflL3HIXMm4fY7Wr:22 a=khIbc0fXALFIcTpOSxgJ:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 060A0B56; Sun, 7 Apr 2019 09:52:36 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x37Gqawe075828; Sun, 7 Apr 2019 09:52:36 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x37GqYU9075823; Sun, 7 Apr 2019 09:52:34 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201904071652.x37GqYU9075823@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: Cy Schubert , "Rodney W. Grimes" , Shawn Webb , Mariusz Zaborski , src-committers , svn-src-all , svn-src-head 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 In-Reply-To: Message from Warner Losh of "Sun, 07 Apr 2019 10:10:34 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-CMAE-Envelope: MS4wfGsk4elrxU6Bw1ajaiU74lmu1w5cgLMMEBUcyaZphA25sDdM/lGb/MxSpvCN0R5HTkHs+LniMvyD78mcN2wrBEXt7qh7+bf4H99sMRQz9gHCBaSzYSCQ 3PTNA1FPofL8+LtPv0coiSrNeu1+tLwtEFXxfUDGJFCSDFpXjNhaLnZFE2fEHrtrGiefAVwOP42NFU4oq6JZMQH7EYvF701o4V34jH2gxRgIGPw5twVUIa1o 75KeZa/MB3r88BS1k0S4h5iodjZuv8ZRBO62WHl3Tiv5M+1PP5ETNoMIlKEVp7kDLvv1JRMLH3bVE5/yTGeAbqFHFbmgemrj/iBi6gmzeIlw5y5R4n3vPt7V 4nAh4bG3olctqlL/RYAbnPT/xpZmidfIdgXkopUASdBfEGFrIsE= Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 3494D97BF8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] Status: O X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:06:31 -0000 X-Original-Date: Sun, 07 Apr 2019 09:52:34 -0700 X-List-Received-Date: Tue, 03 Sep 2019 14:06:31 -0000 In message , Warner Losh writes: > --0000000000005c05ef0585f2f684 > Content-Type: text/plain; charset="UTF-8" > > 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. It's not that simple. A skew may miss an important change to base that will affect ports. Having resulting packages that segfault could be unacceptable outcome. An argument to ignore the jail/pkg version comparison or arbitrarily update it (like my script does) would solve this. However someone not monitoring base commit log commits, an arbitrary argument to poudriere could result in unnecessary mailing list noise or bugzilla tickets, both of which are time wasters. > > 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). That's the other problem. Not everyone will know how a change may affect applications. I suppose the best might be a poudriere flag or config option to ignore jail and pkg version differences and let the human decide. Not all changes affect all ports and those that do should have have a portrevision bump anyway, which BTW is sometimes done. My making kerberos private in base is one such example. There are quite a few ports affected. The exp-run only identified a few who's options don't need kerberos in their default configuration. The more I look the more I discover. The base part of the project was easy (and pretty much ready to commit might I add). Ports OTOH tedious and still much to do. In the very worst case a version bump hardly scratches the surface ... unfortunately. I don't think we can answer this here. Maybe this rises to the level of a developer summit topic one year. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.