From owner-svn-src-head@freebsd.org Tue Sep 22 21:42:16 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 04FB93E0240; Tue, 22 Sep 2020 21:42:16 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bwvsg6QFvz3SZ3; Tue, 22 Sep 2020 21:42:15 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id BB89D1EDF4; Tue, 22 Sep 2020 21:42:15 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f172.google.com with SMTP id w16so20767439qkj.7; Tue, 22 Sep 2020 14:42:15 -0700 (PDT) X-Gm-Message-State: AOAM5306xyZpj9PqpFLbiB4B2Job16RPHNIp6SgubPzr4cV8pGmZqq/3 wcjvRVHET7/6fJqQ2azoVsBBAb6j50JROF1xTb8= X-Google-Smtp-Source: ABdhPJwai0mcdVZ66aEtnZjY5AyU7MmT8kQkkRtY1VKmNOwYpiVwwFpHgh3Ctq8Uj9FRhRLYTkfA4bVdbBJ6jRwh2mg= X-Received: by 2002:a05:620a:4fb:: with SMTP id b27mr7321424qkh.120.1600810935355; Tue, 22 Sep 2020 14:42:15 -0700 (PDT) MIME-Version: 1.0 References: <202009112049.08BKnavL032212@repo.freebsd.org> In-Reply-To: From: Kyle Evans Date: Tue, 22 Sep 2020 16:42:03 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r365643 - head/bin/cp To: Warner Losh Cc: Alan Somers , Kyle Evans , Mateusz Guzik , src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" 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: Tue, 22 Sep 2020 21:42:16 -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? 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