From owner-svn-src-all@freebsd.org Tue Jun 25 13:24:29 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 2C1F415CC8E6; Tue, 25 Jun 2019 13:24:29 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 933E28B02B; Tue, 25 Jun 2019 13:24:28 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x5PDONt2049601; Tue, 25 Jun 2019 06:24:23 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x5PDONUQ049600; Tue, 25 Jun 2019 06:24:23 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201906251324.x5PDONUQ049600@gndrsh.dnsmgr.net> Subject: Re: svn commit: r349352 - in head: etc/mtree include lib lib/libnandfs sbin sbin/camcontrol sbin/nandfs sbin/newfs_nandfs share/man/man4 share/man/man5 share/mk stand stand/arm/uboot stand/common stand... In-Reply-To: To: Warner Losh Date: Tue, 25 Jun 2019 06:24:23 -0700 (PDT) CC: Warner Losh , src-committers , svn-src-all , svn-src-head Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 933E28B02B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.93 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.93)[-0.929,0] 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: Tue, 25 Jun 2019 13:24:29 -0000 > This commit accidentally reverted r349333, r349334, r349335, r349336, > r349339, r349340, r349341 and r349342. I rebased after one of the make > universes I did to proof this set and something must have gone wrong and I > lost these changes. I noticed while committing, but didn't hit ^C fast > enough to prevent the damage it seems. > > I've reapplied those changes rather than revert this commit for two > reasons: first, reverting commits that delete things has caused me trouble > in the past. Second, I judge that to be less repo-churn than doing the > revert, then redoing the nand* removal. > > Time was of the essence, so I hope my snap-judgement was sound. My > apologies both for the 'oops' and for any other fallout. Though this may of reduced repo churn it also broke any MFC that may of been marked in those sets. I am not even sure how one would untwist that maze. MFC original commit is going to leave your second commit as wrongly avaliable commit, so that needs dealt with. MFC your reapply commit, which they have to get by noting these commits as the new merge number. Again, leaving a danglying merge avaliable commit MFC the original commit, your mangle commit, but only the part that applies to there original commit, and the reapply commit. This marks the mangle as merged, but does infact leave the merge avail list for head correct. None of that is very pretty. There are some other options... Anyway my main reason for writting is somehow we need to get out of this "repo churn is expensive I must not revert!" mode of operations. Reverts are almost always the correct way to clean up a mistake, and it almost always leeds to other issues to not revert and instead try to do some magic like what was done here. It is also often a mistake to not exactly revert the original commit, commit that, then commit any additional fix. Reverting and making other changes in the same commit leads to problems more often than it solves them. I do understand the tree might not be in a buildable or correct state for a commit or two. Regards, Rod > Warner > > On Mon, Jun 24, 2019 at 10:50 PM Warner Losh wrote: > > > Author: imp > > Date: Tue Jun 25 04:50:09 2019 > > New Revision: 349352 > > URL: https://svnweb.freebsd.org/changeset/base/349352 > > > > Log: > > Remove NAND and NANDFS support > > > > NANDFS has been broken for years. Remove it. The NAND drivers that > > remain are for ancient parts that are no longer relevant. They are > > polled, have terrible performance and just for ancient arm > > hardware. NAND parts have evolved significantly from this early work > > and little to none of it would be relevant should someone need to > > update to support raw nand. This code has been off by default for > > years and has violated the vnode protocol leading to panics since it > > was committed. > > > > Numerous posts to arch@ and other locations have found no actual users > > for this software. > > > > Relnotes: Yes > > No Objection From: arch@ > > Differential Revision: https://reviews.freebsd.org/D20745 > > ... -- Rod Grimes rgrimes@freebsd.org