Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Apr 2023 17:07:07 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Jessica Clarke <jrtc27@freebsd.org>
Cc:        Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>,  "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>,  "<dev-commits-src-main@freebsd.org>" <dev-commits-src-main@freebsd.org>
Subject:   Re: git: 238271f4a66b - main - stand: Add a snarky note about the upstream ZFS situation
Message-ID:  <CANCZdfr6%2BXsedE690%2BmR3zug6ZOGRErsLg%2BHhWsuB2nYcS-0zg@mail.gmail.com>
In-Reply-To: <B84E9112-427A-4B93-940A-A7734D00A3AB@freebsd.org>
References:  <202304182131.33ILVSoG020217@gitrepo.freebsd.org> <C898F70B-7CA2-451F-A080-ADBFB472561D@freebsd.org> <CANCZdfry1T-xy-xQ19Cch42qmeNNAHFgQf_W61FCbSHWis_aNg@mail.gmail.com> <B84E9112-427A-4B93-940A-A7734D00A3AB@freebsd.org>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On Tue, Apr 18, 2023 at 4:52 PM Jessica Clarke <jrtc27@freebsd.org> wrote:

> On 18 Apr 2023, at 23:49, Warner Losh <imp@bsdimp.com> wrote:
> >
> >
> >
> > On Tue, Apr 18, 2023, 3:34 PM Jessica Clarke <jrtc27@freebsd.org> wrote:
> >> On 18 Apr 2023, at 22:31, Warner Losh <imp@FreeBSD.org> wrote:
> >> >
> >> > The branch main has been updated by imp:
> >> >
> >> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=238271f4a66bd06b8b9a232a82f3ee0882e4cbb9
> >> >
> >> > commit 238271f4a66bd06b8b9a232a82f3ee0882e4cbb9
> >> > Author:     Warner Losh <imp@FreeBSD.org>
> >> > AuthorDate: 2023-04-18 21:29:45 +0000
> >> > Commit:     Warner Losh <imp@FreeBSD.org>
> >> > CommitDate: 2023-04-18 21:31:17 +0000
> >> >
> >> >    stand: Add a snarky note about the upstream ZFS situation
> >> >
> >> >    The latest import of openzfs broke the hacks that we used to omit
> the
> >> >    special registers being used on arm64. Add snarky note documenting
> this
> >> >    situation since it's a mess now since the hack was only partially
> >> >    undone, leaving behind a mess.
> >> >
> >> >    Sponsored by:           Netflix
> >> > ---
> >> > stand/libsa/zfs/Makefile.inc | 4 ++++
> >> > 1 file changed, 4 insertions(+)
> >> >
> >> > diff --git a/stand/libsa/zfs/Makefile.inc
> b/stand/libsa/zfs/Makefile.inc
> >> > index f4cecdbc3085..7660f4ab7baf 100644
> >> > --- a/stand/libsa/zfs/Makefile.inc
> >> > +++ b/stand/libsa/zfs/Makefile.inc
> >> > @@ -19,6 +19,7 @@ ZSTD_SRC+=  zstd_common.c
> >> > ZSTD_SRC+=    zstd_ddict.c zstd_decompress.c zstd_decompress_block.c
> >> > ZSTD_SRC+=    zstd_double_fast.c zstd_fast.c zstd_lazy.c zstd_ldm.c
> >> >
> >> > +# This is completely bogus: We should be able to omit this code
> completely.
> >> > .if ${MACHINE_ARCH} == "aarch64"
> >> > ZFS_SRC_AS =  b3_aarch64_sse2.S b3_aarch64_sse41.S
> >> > .endif
> >> > @@ -90,10 +91,13 @@ CFLAGS.skein_block.c+=    -DSKEIN_LOOP=111
> >> >
> >> > # To find blake3_impl.c in OpenZFS tree for our somehat ugly
> blake3_impl_hack.c
> >> > # that's needed until the necessary tweaks can be upstreamed.
> >> > +# XXX the last import gutted all this since upstream changes broke
> this hack.
> >> > CFLAGS.blake3_impl_hack.c+= -I${OZFS}/module/icp/algs/blake3
> -I${OZFS}/module/icp/include
> >> >
> >> > CWARNFLAGS.zfs.c+= ${NO_WDANGLING_POINTER}
> >> >
> >> > +# Needing to remove the -mgeneral-regs-only is a red flag that this
> is not quite
> >> > +# right. But it's needed at the moment due to the muddled upstream.
> >>
> >> This one isn’t bogus? The file is deliberately using NEON so needs
> >> access to floating-point registers, which LLVM (mostly) enforces for
> >> the assembler, unlike GNU as.
> >
> > No. It's bogus because we should not be using it at all. The generic
> implementation is fast enough for the boot loader and we have a blanket
> policy against using extra register sets. The change wasn't discussed
> before hand and what's really needed are upstream changes to be able to
> omit it entirely.
>
> Oh I see, I misunderstood the point the comment was making.
>

It's also the third or fourth time that I've had to sort this, or similar,
issues out in the boot loader (after spending a week or two initially to
enable the OpenZFS import), so I'm a little frustrated by the situation.

Warner


> Thanks,
> Jess
>
> > > b3_aarch64_sse2.o: b3_aarch64_sse2.S
> > >       ${CC} -c ${CFLAGS:N-mgeneral-regs-only} ${WERROR} ${.IMPSRC} \
> > >           -o ${.TARGET}
>
>

[-- Attachment #2 --]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 18, 2023 at 4:52 PM Jessica Clarke &lt;<a href="mailto:jrtc27@freebsd.org">jrtc27@freebsd.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 18 Apr 2023, at 23:49, Warner Losh &lt;<a href="mailto:imp@bsdimp.com" target="_blank">imp@bsdimp.com</a>&gt; wrote:<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; On Tue, Apr 18, 2023, 3:34 PM Jessica Clarke &lt;<a href="mailto:jrtc27@freebsd.org" target="_blank">jrtc27@freebsd.org</a>&gt; wrote:<br>
&gt;&gt; On 18 Apr 2023, at 22:31, Warner Losh &lt;imp@FreeBSD.org&gt; wrote:<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; The branch main has been updated by imp:<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; URL: <a href="https://cgit.FreeBSD.org/src/commit/?id=238271f4a66bd06b8b9a232a82f3ee0882e4cbb9" rel="noreferrer" target="_blank">https://cgit.FreeBSD.org/src/commit/?id=238271f4a66bd06b8b9a232a82f3ee0882e4cbb9</a><br>;
&gt;&gt; &gt; <br>
&gt;&gt; &gt; commit 238271f4a66bd06b8b9a232a82f3ee0882e4cbb9<br>
&gt;&gt; &gt; Author:     Warner Losh &lt;imp@FreeBSD.org&gt;<br>
&gt;&gt; &gt; AuthorDate: 2023-04-18 21:29:45 +0000<br>
&gt;&gt; &gt; Commit:     Warner Losh &lt;imp@FreeBSD.org&gt;<br>
&gt;&gt; &gt; CommitDate: 2023-04-18 21:31:17 +0000<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt;    stand: Add a snarky note about the upstream ZFS situation<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt;    The latest import of openzfs broke the hacks that we used to omit the<br>
&gt;&gt; &gt;    special registers being used on arm64. Add snarky note documenting this<br>
&gt;&gt; &gt;    situation since it&#39;s a mess now since the hack was only partially<br>
&gt;&gt; &gt;    undone, leaving behind a mess.<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt;    Sponsored by:           Netflix<br>
&gt;&gt; &gt; ---<br>
&gt;&gt; &gt; stand/libsa/zfs/Makefile.inc | 4 ++++<br>
&gt;&gt; &gt; 1 file changed, 4 insertions(+)<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; diff --git a/stand/libsa/zfs/Makefile.inc b/stand/libsa/zfs/Makefile.inc<br>
&gt;&gt; &gt; index f4cecdbc3085..7660f4ab7baf 100644<br>
&gt;&gt; &gt; --- a/stand/libsa/zfs/Makefile.inc<br>
&gt;&gt; &gt; +++ b/stand/libsa/zfs/Makefile.inc<br>
&gt;&gt; &gt; @@ -19,6 +19,7 @@ ZSTD_SRC+=  zstd_common.c<br>
&gt;&gt; &gt; ZSTD_SRC+=    zstd_ddict.c zstd_decompress.c zstd_decompress_block.c<br>
&gt;&gt; &gt; ZSTD_SRC+=    zstd_double_fast.c zstd_fast.c zstd_lazy.c zstd_ldm.c<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; +# This is completely bogus: We should be able to omit this code completely.<br>
&gt;&gt; &gt; .if ${MACHINE_ARCH} == &quot;aarch64&quot;<br>
&gt;&gt; &gt; ZFS_SRC_AS =  b3_aarch64_sse2.S b3_aarch64_sse41.S<br>
&gt;&gt; &gt; .endif<br>
&gt;&gt; &gt; @@ -90,10 +91,13 @@ CFLAGS.skein_block.c+=    -DSKEIN_LOOP=111<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; # To find blake3_impl.c in OpenZFS tree for our somehat ugly blake3_impl_hack.c<br>
&gt;&gt; &gt; # that&#39;s needed until the necessary tweaks can be upstreamed.<br>
&gt;&gt; &gt; +# XXX the last import gutted all this since upstream changes broke this hack.<br>
&gt;&gt; &gt; CFLAGS.blake3_impl_hack.c+= -I${OZFS}/module/icp/algs/blake3 -I${OZFS}/module/icp/include<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; CWARNFLAGS.zfs.c+= ${NO_WDANGLING_POINTER}<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; +# Needing to remove the -mgeneral-regs-only is a red flag that this is not quite<br>
&gt;&gt; &gt; +# right. But it&#39;s needed at the moment due to the muddled upstream.<br>
&gt;&gt; <br>
&gt;&gt; This one isn’t bogus? The file is deliberately using NEON so needs<br>
&gt;&gt; access to floating-point registers, which LLVM (mostly) enforces for<br>
&gt;&gt; the assembler, unlike GNU as.<br>
&gt; <br>
&gt; No. It&#39;s bogus because we should not be using it at all. The generic implementation is fast enough for the boot loader and we have a blanket policy against using extra register sets. The change wasn&#39;t discussed before hand and what&#39;s really needed are upstream changes to be able to omit it entirely.<br>
<br>
Oh I see, I misunderstood the point the comment was making.<br></blockquote><div><br></div><div>It&#39;s also the third or fourth time that I&#39;ve had to sort this, or similar, issues out in the boot loader (after spending a week or two initially to enable the OpenZFS import), so I&#39;m a little frustrated by the situation.</div><div><br></div><div>Warner</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Jess<br>
<br>
&gt; &gt; b3_aarch64_sse2.o: b3_aarch64_sse2.S<br>
&gt; &gt;       ${CC} -c ${CFLAGS:N-mgeneral-regs-only} ${WERROR} ${.IMPSRC} \<br>
&gt; &gt;           -o ${.TARGET}<br>
<br>
</blockquote></div></div>
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr6%2BXsedE690%2BmR3zug6ZOGRErsLg%2BHhWsuB2nYcS-0zg>