From owner-svn-src-head@freebsd.org Wed Sep 23 16:56:54 2020 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 B2C0D3FF027; Wed, 23 Sep 2020 16:56:54 +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 4BxPTx3BkJz3c3B; Wed, 23 Sep 2020 16:56:53 +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 08NGujEQ042901; Wed, 23 Sep 2020 09:56:45 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 08NGujEs042900; Wed, 23 Sep 2020 09:56:45 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <202009231656.08NGujEs042900@gndrsh.dnsmgr.net> Subject: Re: svn commit: r365643 - head/bin/cp In-Reply-To: To: Kyle Evans Date: Wed, 23 Sep 2020 09:56:45 -0700 (PDT) CC: Warner Losh , Alan Somers , Mateusz Guzik , 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: 4BxPTx3BkJz3c3B X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.62 / 15.00]; HAS_REPLYTO(0.00)[rgrimes@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.12)[0.121]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.44)[0.442]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.15)[0.153]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MAILMAN_DEST(0.00)[svn-src-all,svn-src-head]; FREEMAIL_CC(0.00)[bsdimp.com,freebsd.org,gmail.com] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 16:56:54 -0000 > cp is already fixed, people are still feeling the fallout of being > within those revisions and needing to bootstrap their own cp. We can > reduce the number of components these invocations rely on trivially to > shell built-in mechanics, why not do so? I would even go further, I would like to see the dependency on /dev/null removed from the build, and the boot process. >From the build because it means I would no longer have to mount /dev in my chroots, and from the boot because I hate to say it, but we often scribble in /dev before devfs is mounted and if you look at root file systems mounted on other systems you well often find a /dev/null FILE that got created during the boot process from a >/dev/null before devfs was mounted. > > On Tue, Sep 22, 2020 at 4:40 PM Warner Losh wrote: > > > > So why do we need a workaround at all? cp /dev/null has been fixed, and that's way more important to get right. > > > > I don't want to paper-over issues with this at all, though if we use the host's (now broken) cp, I suppose that might be OK in the short term. If that's the case, then maybe this is OK. > > > > Otherwise, I'd strongly prefer we fix cp. > > > > Warner > > > > On Tue, Sep 22, 2020 at 3:31 PM Alan Somers wrote: > >> > >> +1. > >> > >> On Tue, Sep 22, 2020 at 3:27 PM Kyle Evans wrote: > >>> > >>> I'm running a build at the suggestion of mjg to confirm there aren't > >>> any others hiding that can be converted, and I will commit after I've > >>> verified that this is it. > >>> > >>> On Tue, Sep 22, 2020 at 4:02 PM Alan Somers wrote: > >>> > > >>> > LGTM. > >>> > > >>> > On Tue, Sep 22, 2020 at 2:59 PM Kyle Evans wrote: > >>> >> > >>> >> Perhaps: > >>> >> > >>> >> diff --git a/stand/i386/zfsboot/Makefile b/stand/i386/zfsboot/Makefile > >>> >> index ff315abc0ef..7e362b43a39 100644 > >>> >> --- a/stand/i386/zfsboot/Makefile > >>> >> +++ b/stand/i386/zfsboot/Makefile > >>> >> @@ -81,7 +81,7 @@ zfsboot.ld: zfsboot.ldr zfsboot.bin ${BTXKERN} > >>> >> -o ${.TARGET} -P 1 zfsboot.bin > >>> >> > >>> >> zfsboot.ldr: > >>> >> - cp /dev/null ${.TARGET} > >>> >> + :> ${.TARGET} > >>> >> > >>> >> zfsboot.bin: zfsboot.out > >>> >> ${OBJCOPY} -S -O binary zfsboot.out ${.TARGET} > >>> >> diff --git a/stand/libsa/Makefile b/stand/libsa/Makefile > >>> >> index effece9e01b..63cd46a9c54 100644 > >>> >> --- a/stand/libsa/Makefile > >>> >> +++ b/stand/libsa/Makefile > >>> >> @@ -122,7 +122,7 @@ beforedepend: > >>> >> ln -sf ${SRCTOP}/include/arpa/inet.h arpa/inet.h; \ > >>> >> ln -sf ${SRCTOP}/include/arpa/tftp.h arpa/tftp.h; \ > >>> >> for i in _time.h _strings.h _string.h; do \ > >>> >> - [ -f xlocale/$$i ] || cp /dev/null xlocale/$$i; \ > >>> >> + [ -f xlocale/$$i ] || :> xlocale/$$i; \ > >>> >> done; \ > >>> >> for i in ${STAND_H_INC}; do \ > >>> >> ln -sf ${SASRC}/stand.h $$i; \ > >>> >> > >>> >> > >>> >> On Tue, Sep 22, 2020 at 3:58 PM Alan Somers wrote: > >>> >> > > >>> >> > Looks like two places in stand. Is there any reason why Mateusz's suggestion wouldn't work? > >>> >> > > >>> >> > > rg -g Makefile 'cp.*/dev/null' > >>> >> > stand/libsa/Makefile > >>> >> > 125: [ -f xlocale/$$i ] || cp /dev/null xlocale/$$i; \ > >>> >> > > >>> >> > stand/i386/zfsboot/Makefile > >>> >> > 82: cp /dev/null ${.TARGET} > >>> >> > > >>> >> > On Tue, Sep 22, 2020 at 2:54 PM Mateusz Guzik wrote: > >>> >> >> > >>> >> >> Can we instead add a workaround to the build tree? > >>> >> >> > >>> >> >> Where is cp /dev/null coming from anyway? Perhaps this can be patched > >>> >> >> to touch the target file. > >>> >> >> > >>> >> >> On 9/22/20, Alan Somers wrote: > >>> >> >> > On Tue, Sep 22, 2020 at 2:48 PM Kyle Evans wrote: > >>> >> >> > > >>> >> >> >> On Fri, Sep 11, 2020 at 3:49 PM Alan Somers wrote: > >>> >> >> >> > > >>> >> >> >> > Author: asomers > >>> >> >> >> > Date: Fri Sep 11 20:49:36 2020 > >>> >> >> >> > New Revision: 365643 > >>> >> >> >> > URL: https://svnweb.freebsd.org/changeset/base/365643 > >>> >> >> >> > > >>> >> >> >> > Log: > >>> >> >> >> > cp: fall back to read/write if copy_file_range fails > >>> >> >> >> > > >>> >> >> >> > Even though copy_file_range has a file-system agnostic version, it > >>> >> >> >> still > >>> >> >> >> > fails on devfs (perhaps because the file descriptor is non-seekable?) > >>> >> >> >> In > >>> >> >> >> > that case, fallback to old-fashioned read/write. Fixes > >>> >> >> >> > "cp /dev/null /tmp/null" > >>> >> >> >> > > >>> >> >> >> > >>> >> >> >> Hi, > >>> >> >> >> > >>> >> >> >> Any objection to adding a quick UPDATING entry for this? I'm seeing > >>> >> >> >> occasional reports of this breakage as recent as today on IRC from > >>> >> >> >> folks that were a little bit thrown off by this because it throws up > >>> >> >> >> fairly far into the build and looks like a stand build regression > >>> >> >> >> instead of a cp regression. > >>> >> >> >> > >>> >> >> >> Thanks, > >>> >> >> >> > >>> >> >> >> Kyle Evans > >>> >> >> >> > >>> >> >> > > >>> >> >> > No objection. Can you suggest the proper wording? > >>> >> >> > _______________________________________________ > >>> >> >> > svn-src-all@freebsd.org mailing list > >>> >> >> > https://lists.freebsd.org/mailman/listinfo/svn-src-all > >>> >> >> > To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" > >>> >> >> > > >>> >> >> > >>> >> >> > >>> >> >> -- > >>> >> >> Mateusz Guzik > -- Rod Grimes rgrimes@freebsd.org