> 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 <i...@bsdimp.com> 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 <asom...@freebsd.org> wrote: > >> > >> +1. > >> > >> On Tue, Sep 22, 2020 at 3:27 PM Kyle Evans <kev...@freebsd.org> 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 <asom...@freebsd.org> wrote: > >>> > > >>> > LGTM. > >>> > > >>> > On Tue, Sep 22, 2020 at 2:59 PM Kyle Evans <kev...@freebsd.org> 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 <asom...@freebsd.org> > >>> >> 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 <mjgu...@gmail.com> > >>> >> > 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 <asom...@freebsd.org> wrote: > >>> >> >> > On Tue, Sep 22, 2020 at 2:48 PM Kyle Evans <kev...@freebsd.org> > >>> >> >> > wrote: > >>> >> >> > > >>> >> >> >> On Fri, Sep 11, 2020 at 3:49 PM Alan Somers > >>> >> >> >> <asom...@freebsd.org> 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-...@freebsd.org mailing list > >>> >> >> > https://lists.freebsd.org/mailman/listinfo/svn-src-all > >>> >> >> > To unsubscribe, send any mail to > >>> >> >> > "svn-src-all-unsubscr...@freebsd.org" > >>> >> >> > > >>> >> >> > >>> >> >> > >>> >> >> -- > >>> >> >> Mateusz Guzik <mjguzik gmail.com> > -- Rod Grimes rgri...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"