From nobody Tue Feb 06 00:15:36 2024 X-Original-To: dev-commits-src-all@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 4TTP0g4yd9z59LTG for ; Tue, 6 Feb 2024 00:15:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 4TTP0f71nVz49ss for ; Tue, 6 Feb 2024 00:15:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=ZyTeDH5D; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::532) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5605c7b0ca2so2055632a12.3 for ; Mon, 05 Feb 2024 16:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1707178545; x=1707783345; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y0q5DMomjYKNPBjd3d0KfKk9I4GCfSPshP8O1e07oYI=; b=ZyTeDH5DzmlbiJhLyS1hxJzPIjnsrzfY9sk+151b99A6xgt0s/rJ9cFBnul0bIgIXV O3MM/QqJHZ9vtxeZgsCE5PXGcbm9DJYBQyEzbd805qd7CWr2cbehYyLfIblVVnpIkf26 LIWcJ+xmks0fosVlLeZr16MGQ9w2pu/4pwS9uTJlbKMekUj34mWCbJjL941FXyK+oIeA +EkLhva3k011nPYyd2jPXRuXqTp7gWfhNdrUse7ZjuQ2jHUtJD/gL9cBp6fpuSYPOz9r ggXgFDZTVFjfBpZT6rgpSQyX1bLw48lkAMuOG+0GBxtRdpaCO1Unchbes8eW9ITh7J// cvIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707178545; x=1707783345; 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=y0q5DMomjYKNPBjd3d0KfKk9I4GCfSPshP8O1e07oYI=; b=EhEfXibw57yb4Yt/htZ1Jh8RLt6WiOZypCAFHNyrFLTrgtMqL2mV2Mt6y53b1KdYCU 5MUaKe0mEtArTLkMXY+iPBz/UyGAWnqasPlMX1LN64o5RayJpBi+3qCj/8iI4k8q4Hl9 V+q56ux0NFMUsJJcfj+4xeARBKXpcoUdoaXt0dJtKj5kRbQZ1R3jVe7cM54hCDqsFCtr ubRAD9cJZSRxUFLC/PDYSoQh/DLWsgjd6L6GL+NqQCnVtU0itFCXKhfftv0xNjXGOMIB bWuIKdkER0CbfW7jzv0CybUv3WlF9UhwtbNUDJCPkk3pTRs0Kj7rCldpFsu5Ef8oBjQH 5XCA== X-Gm-Message-State: AOJu0YyjpUY8KCY/lOXMfzC//LPpWcTi2EiV2adMxSt9tobKMbBnGhjH Vt620kYekwYKRBKuKuzNixvag7A6yt/6KHDU5lz2lrRb8TUQtUs9cWuHcGPNUxQlw+Q0tsbKQcA NK+xqfFFXYlYxpsZ4xoLWwfJvxQ7IwT1k4xe8pg== X-Google-Smtp-Source: AGHT+IEOyp0qxCDdxKMaT0sM1Qdv9YVqCamS7L+MBshAF+q+icf++hd7Uu5JvstwonY2SlfDYUVEiRfivE1PUg9sXRA= X-Received: by 2002:a05:6402:1203:b0:560:64f4:cbd5 with SMTP id c3-20020a056402120300b0056064f4cbd5mr518785edw.21.1707178545532; Mon, 05 Feb 2024 16:15:45 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <737703f2-26a6-4a84-a64b-3fa55cad721c@FreeBSD.org> <20240131204355.9EA2B19F@slippy.cwsent.com> In-Reply-To: From: Warner Losh Date: Mon, 5 Feb 2024 17:15:36 -0700 Message-ID: Subject: Re: git: 07c64d74917e - main - acpica: Import ACPICA 20230628 To: Cy Schubert Cc: Andriy Gapon , Jung-uk Kim , Baptiste Daroussin , src-committers , "" , "" , Dmitry Salychev Content-Type: multipart/alternative; boundary="000000000000c66e3d0610ab7a3a" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_SEVEN(0.00)[8]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-all@freebsd.org]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4TTP0f71nVz49ss --000000000000c66e3d0610ab7a3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 5, 2024 at 8:55=E2=80=AFAM Warner Losh wrote: > > > On Mon, Feb 5, 2024 at 8:34=E2=80=AFAM Warner Losh wrote= : > >> >> >> On Wed, Jan 31, 2024 at 1:59=E2=80=AFPM Warner Losh wro= te: >> >>> >>> >>> On Wed, Jan 31, 2024, 1:44=E2=80=AFPM Cy Schubert >>> wrote: >>> >>>> In message <737703f2-26a6-4a84-a64b-3fa55cad721c@FreeBSD.org>, Andriy >>>> Gapon >>>> wri >>>> tes: >>>> > On 31/01/2024 19:40, Cy Schubert wrote: >>>> > > In message <04c4a0e1-aa79-4d25-a1f7-2196cfa65578@FreeBSD.org>, >>>> Jung-uk Kim >>>> > > writ >>>> > > es: >>>> > >> On 24. 1. 31., Baptiste Daroussin wrote: >>>> > >>> Hello, >>>> > >>> >>>> > >>> Either this one or the previous import is breaking arm64 build >>>> > >>> >>>> > >>> --- acpi_iort.o --- >>>> > >>> /home/bapt/worktrees/main/sys/arm64/acpica/acpi_iort.c:103:4: >>>> error: fiel >>>> > d >>>> > >>> 'data' with variable sized type 'union (unnamed union at >>>> > >>> /home/bapt/worktrees/main/sys/arm64/acpica/acpi_iort.c:98:2 >>>> > >>> )' not at the end of a struct or class is a GNU extension >>>> > >>> [-Werror,-Wgnu-variable-sized-type-not-at-end] >>>> > >>> 103 | } data; >>>> > >>> | ^ >>>> > >> >>>> > >> Sorry for the breakage. I will fix it soon. >>>> > >> >>>> > >> BTW, this code was added by this: >>>> > >> >>>> > >> https://reviews.freebsd.org/D31267 >>>> > >> >>>> > >> It seems struct iort_named_component was a hack, which duplicated >>>> > >> ACPI_IORT_NAMED_COMPONENT but with a fixed length field >>>> DeviceName[32]. >>>> > >> Is it really necessary? >>>> > > >>>> > > Though they incorporated the WOL patch I've been using, they've >>>> broken >>>> > > poweroff. >>>> > >>>> > The poweroff issue could be because of 9cdf326b4f >>>> >>>> Thanks. I clued into that a while ago after taking a break to read the >>>> ML. >>>> >>>> This smelled of the original WOL problem I had last year that required >>>> pulling the plug to allow the NIC to see the magic packet, but worse. >>>> Hence >>>> I was barking up the wrong tree. >>>> >>> >>> On an semi-related issue... mind if I do a proper merge commit to catch >>> up and not leave hidden landmines for the future? >>> >> >> OK. I'll do a proper merge commit. We've accumulated a few dozen >> conflicts I'll have to sort out (though I think they >> are all in files we don't user or have deleted). >> > > After resolving the conflicts, it's one file (limts.h) that's now include= d > where it wasn't before. Once I make sure that world and kernel still buil= d, > I'll push the change since limits.h isn't going to affect any functionali= ty > and I may need to ifdef it for the kernel anyay... > > Many of the conflicts could be avoided if we didn't modify the files like > we do. I'll see about working up a patch, either myself or someone else w= ho > has interest, and submitting it for review. This would make future merges > even easier since the changes we've made are all build-system related and > need manual intervention today. > I've merged the merge commit with the one fixup. I'm also thinking that we can stop doing the transforms that we do on import that make it harder than it needs to be to continue merging. Slight changes to the build infrastructure, as well as git's vastly better merging abilities should allow us to drop about 2k lines of diffs, allowing us to audit the delta with upstream, which currently is all-in at: 347 files changed, 2891 insertions(+), 1700 deletions(-) which is kinda hard to audit for correctness. The vast majority of the files changed are just hacking headers that's better done with the build system. Once that's fixed we can look at why we have 6 files that have over 100 lines of difference each (much if it has the feel of mismerges rather than intention). Warner > > Warner >>> >>>> >>>> -- >>>> Cheers, >>>> Cy Schubert >>>> FreeBSD UNIX: Web: https://FreeBSD.org >>>> NTP: Web: https://nwtime.org >>>> >>>> e^(i*pi)+1=3D0 >>>> >>>> >>>> --000000000000c66e3d0610ab7a3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 5, 2024 at 8:55=E2=80=AFA= M Warner Losh <imp@bsdimp.com> = wrote:


On Mon, Feb 5, 2024 at 8:34=E2=80=AFAM Warner= Losh <imp@bsdimp.co= m> wrote:


On Wed, Jan 31, 2024 at 1:59=E2=80= =AFPM Warner Losh <i= mp@bsdimp.com> wrote:


On Wed, Jan 31, 2024, 1:44=E2=80=AFPM Cy = Schubert <Cy.Schubert@cschubert.com> wrote:
In message <737703f2-26a6-4a84-a64b-3fa55cad72= 1c@FreeBSD.org>, Andriy Gapon
wri
tes:
> On 31/01/2024 19:40, Cy Schubert wrote:
> > In message <04c4a0e1-aa79-4d25-a1f7-2196cfa65578@FreeBSD.org&g= t;, Jung-uk Kim
> > writ
> > es:
> >> On 24. 1. 31., Baptiste Daroussin wrote:
> >>> Hello,
> >>>
> >>> Either this one or the previous import is breaking arm64 = build
> >>>
> >>> --- acpi_iort.o ---
> >>> /home/bapt/worktrees/main/sys/arm64/acpica/acpi_iort.c:10= 3:4: error: fiel
> d
> >>> 'data' with variable sized type 'union (unnam= ed union at
> >>> /home/bapt/worktrees/main/sys/arm64/acpica/acpi_iort.c:98= :2
> >>> )' not at the end of a struct or class is a GNU exten= sion
> >>> [-Werror,-Wgnu-variable-sized-type-not-at-end]
> >>>=C2=A0 =C2=A0 =C2=A0103 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0} data;
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0^
> >>
> >> Sorry for the breakage.=C2=A0 I will fix it soon.
> >>
> >> BTW, this code was added by this:
> >>
> >> https://reviews.freebsd.org/D31267 > >>
> >> It seems struct iort_named_component was a hack, which duplic= ated
> >> ACPI_IORT_NAMED_COMPONENT but with a fixed length field Devic= eName[32].
> >> Is it really necessary?
> >
> > Though they incorporated the WOL patch I've been using, they&= #39;ve broken
> > poweroff.
>
> The poweroff issue could be because of 9cdf326b4f

Thanks. I clued into that a while ago after taking a break to read the ML.<= br>
This smelled of the original WOL problem I had last year that required
pulling the plug to allow the NIC to see the magic packet, but worse. Hence=
I was barking up the wrong tree.

On an semi-related issue... mind if I do a = proper merge commit to catch up and not leave hidden landmines for the futu= re?

OK. I'll do a proper me= rge commit. We've accumulated a few dozen conflicts I'll have to so= rt out (though I think they
are all in files we don't user or= have deleted).

After res= olving the conflicts, it's one file (limts.h) that's now included w= here it wasn't before. Once I make sure that world and kernel still bui= ld, I'll push the change since limits.h isn't going to affect any f= unctionality and I may need to ifdef it for the kernel anyay...

Many of the conflicts could be avoided if we didn't m= odify the files like we do. I'll see about working up a patch, either m= yself or someone else who has interest, and submitting it for review. This = would make future merges even easier since the changes we've made are a= ll build-system related and need manual intervention today.

I've merged the merge commit with th= e one fixup.

I'm also thinking that we can sto= p doing the transforms that we do on import that make it harder than it nee= ds to be to continue merging. Slight changes to the build infrastructure, a= s well as git's vastly better merging abilities should allow us to drop= about 2k lines of diffs, allowing us to audit the delta with upstream, whi= ch currently is all-in at:
=C2=A0347 files changed, 2891 insertio= ns(+), 1700 deletions(-)
which is kinda hard to audit for correct= ness. The vast majority of the files changed are just hacking headers that&= #39;s better done with the build system. Once that's fixed we can look = at why we have 6 files that have over 100 lines of difference each (much if= it has the feel of mismerges rather than intention).

<= div>Warner
=C2=A0

Warner

--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 ht= tps://FreeBSD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2= =A0 Web:=C2=A0 https://nwtime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0


--000000000000c66e3d0610ab7a3a--