From nobody Tue Apr 18 22:49:57 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q1Jz61Ydqz45nnS for ; Tue, 18 Apr 2023 22:50:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q1Jz56dFkz3KBt for ; Tue, 18 Apr 2023 22:50:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5055141a8fdso4450923a12.3 for ; Tue, 18 Apr 2023 15:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1681858208; x=1684450208; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Wq9w/l4DaUpd84iLmwFjxLrL4ATpMql6Uvgo19amebM=; b=I03tJQALgXKyswVxkylDoeo3LElbgzX44Rhd/t5sLdfLduRgncVdcyjiW7Y8gpjFcB SVmdg3jIBeU/pmaMlsUZ7HidBx8M1p+G+BNyW/4nHtymR/56ip7kOBvz7AE3nak1uB6J ES0DlqJg7+HHRnkDUiTlPzwa1M7pJjK8tTiQSFgOTqYZ40yEXt7IIu5BCF5sTaXbyIAv bHCquWPfAL9Q0cK0sE/bKbD0es9QK9VqGq7eBFffTfKn1pjGyTTGQEHYrM+AzgLR6Q6k pdSbUed7Ozdvan0NpJTmv+wHufEiM/OVcLImXRzytema4A1SxxO+xRMCTJaG0i3IiIYB adfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681858208; x=1684450208; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Wq9w/l4DaUpd84iLmwFjxLrL4ATpMql6Uvgo19amebM=; b=lqH1+WctSM7o59WJ1S8v7c8TDP03eXKtze8sZIOsTbc+WpmK7SzNdWfUddcfeYh3E0 3OF0trst8EYdOXi6NbDhfnTZNoskZ3EbS/xVsy38o0af2o4eKG6Fq/qt6acvLD9jKYbP vy/x4mrDkCySiNlKtz5cxVwB/xMnTjByJuVF56WhrJ0Xe0PQYRCfXiPb5bSN00vzormP WoVGN8V7BP5Krf8jrhezFsP6OmZEpJT96RnhToMVaHUd8mQ/OqMOU32YWjWRNYoLd060 bq2Qt3q56tp/rs4rPiG6CASg9UgJKdv0mrmiyUGJwtFz3nUdZS0AQFwLn2b/yyxjf/wd 9f+w== X-Gm-Message-State: AAQBX9cbKxzTMmwborr49tmL15V35ln34eH138A/5BWWo5XgT1etS32L SdDNJVg/Nc7CAK1Wyx7PuyXw9E3XVE0Y+oi8fCqH7A== X-Google-Smtp-Source: AKy350ZN/9wANmI9IqUljNoTPif10nTh5DV1CFf3qVdP0zHXp1ULv3E/vvVjamMsKGGqaX6mD19oib2fdNVQslMbGkI= X-Received: by 2002:aa7:da44:0:b0:506:b8ca:e07e with SMTP id w4-20020aa7da44000000b00506b8cae07emr3721174eds.11.1681858208449; Tue, 18 Apr 2023 15:50:08 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202304182131.33ILVSoG020217@gitrepo.freebsd.org> In-Reply-To: From: Warner Losh Date: Tue, 18 Apr 2023 16:49:57 -0600 Message-ID: Subject: Re: git: 238271f4a66b - main - stand: Add a snarky note about the upstream ZFS situation To: Jessica Clarke Cc: Warner Losh , src-committers , "" , "" Content-Type: multipart/alternative; boundary="00000000000013f2fd05f9a421fb" X-Rspamd-Queue-Id: 4Q1Jz56dFkz3KBt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000013f2fd05f9a421fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 18, 2023, 3:34 PM Jessica Clarke wrote: > On 18 Apr 2023, at 22:31, Warner Losh wrote: > > > > The branch main has been updated by imp: > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=3D238271f4a66bd06b8b9a232a82f3ee0= 882e4cbb9 > > > > commit 238271f4a66bd06b8b9a232a82f3ee0882e4cbb9 > > Author: Warner Losh > > AuthorDate: 2023-04-18 21:29:45 +0000 > > Commit: Warner Losh > > 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 th= e > > 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.in= c > > index f4cecdbc3085..7660f4ab7baf 100644 > > --- a/stand/libsa/zfs/Makefile.inc > > +++ b/stand/libsa/zfs/Makefile.inc > > @@ -19,6 +19,7 @@ ZSTD_SRC+=3D zstd_common.c > > ZSTD_SRC+=3D zstd_ddict.c zstd_decompress.c zstd_decompress_block.c > > ZSTD_SRC+=3D 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} =3D=3D "aarch64" > > ZFS_SRC_AS =3D b3_aarch64_sse2.S b3_aarch64_sse41.S > > .endif > > @@ -90,10 +91,13 @@ CFLAGS.skein_block.c+=3D -DSKEIN_LOOP=3D111 > > > > # 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 thi= s > hack. > > CFLAGS.blake3_impl_hack.c+=3D -I${OZFS}/module/icp/algs/blake3 > -I${OZFS}/module/icp/include > > > > CWARNFLAGS.zfs.c+=3D ${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=E2=80=99t bogus? The file is deliberately using NEON so need= s > 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. Warner Jess > > > b3_aarch64_sse2.o: b3_aarch64_sse2.S > > ${CC} -c ${CFLAGS:N-mgeneral-regs-only} ${WERROR} ${.IMPSRC} \ > > -o ${.TARGET} > > --00000000000013f2fd05f9a421fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 18, 2023, 3:34 PM Jessica Clarke <jrtc27@freebsd.org> wrote:
On 18 Apr 2023, at 22:31, Warner Losh <i= mp@FreeBSD.org> wrote:
>
> The branch main has been updated by imp:
>
> URL: https://cgit.FreeBSD.org/src/commit/?id=3D238271f4a66bd06b8b9a232a82f3ee= 0882e4cbb9
>
> commit 238271f4a66bd06b8b9a232a82f3ee0882e4cbb9
> Author:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
> AuthorDate: 2023-04-18 21:29:45 +0000
> Commit:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
> CommitDate: 2023-04-18 21:31:17 +0000
>
>=C2=A0 =C2=A0 stand: Add a snarky note about the upstream ZFS situation=
>
>=C2=A0 =C2=A0 The latest import of openzfs broke the hacks that we used= to omit the
>=C2=A0 =C2=A0 special registers being used on arm64. Add snarky note do= cumenting this
>=C2=A0 =C2=A0 situation since it's a mess now since the hack was on= ly partially
>=C2=A0 =C2=A0 undone, leaving behind a mess.
>
>=C2=A0 =C2=A0 Sponsored by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Net= flix
> ---
> stand/libsa/zfs/Makefile.inc | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/stand/libsa/zfs/Makefile.inc b/stand/libsa/zfs/Makefile.i= nc
> index f4cecdbc3085..7660f4ab7baf 100644
> --- a/stand/libsa/zfs/Makefile.inc
> +++ b/stand/libsa/zfs/Makefile.inc
> @@ -19,6 +19,7 @@ ZSTD_SRC+=3D=C2=A0 zstd_common.c
> ZSTD_SRC+=3D=C2=A0 =C2=A0 zstd_ddict.c zstd_decompress.c zstd_decompre= ss_block.c
> ZSTD_SRC+=3D=C2=A0 =C2=A0 zstd_double_fast.c zstd_fast.c zstd_lazy.c z= std_ldm.c
>
> +# This is completely bogus: We should be able to omit this code compl= etely.
> .if ${MACHINE_ARCH} =3D=3D "aarch64"
> ZFS_SRC_AS =3D=C2=A0 b3_aarch64_sse2.S b3_aarch64_sse41.S
> .endif
> @@ -90,10 +91,13 @@ CFLAGS.skein_block.c+=3D=C2=A0 =C2=A0 -DSKEIN_LOOP= =3D111
>
> # To find blake3_impl.c in OpenZFS tree for our somehat ugly blake3_im= pl_hack.c
> # that's needed until the necessary tweaks can be upstreamed.
> +# XXX the last import gutted all this since upstream changes broke th= is hack.
> CFLAGS.blake3_impl_hack.c+=3D -I${OZFS}/module/icp/algs/blake3 -I${OZF= S}/module/icp/include
>
> CWARNFLAGS.zfs.c+=3D ${NO_WDANGLING_POINTER}
>
> +# Needing to remove the -mgeneral-regs-only is a red flag that this i= s not quite
> +# right. But it's needed at the moment due to the muddled upstrea= m.

This one isn=E2=80=99t bogus? The file is deliberately using NEON so needs<= br> access to floating-point registers, which LLVM (mostly) enforces for
the assembler, unlike GNU as.

No. It's bogus because we should not be us= ing it at all. The generic implementation is fast enough for the boot loade= r and we have a blanket policy against using extra register sets. The chang= e wasn't discussed before hand and what's really needed are upstrea= m changes to be able to omit it entirely.

=
Warner

Jess

> b3_aarch64_sse2.o: b3_aarch64_sse2.S
>=C2=A0 =C2=A0 =C2=A0 =C2=A0${CC} -c ${CFLAGS:N-mgeneral-regs-only} ${WE= RROR} ${.IMPSRC} \
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-o ${.TARGET}

--00000000000013f2fd05f9a421fb--