Date: Mon, 5 Feb 2024 17:15:36 -0700 From: Warner Losh <imp@bsdimp.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Andriy Gapon <avg@freebsd.org>, Jung-uk Kim <jkim@freebsd.org>, Baptiste Daroussin <bapt@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>, Dmitry Salychev <dsl@mcusim.org> Subject: Re: git: 07c64d74917e - main - acpica: Import ACPICA 20230628 Message-ID: <CANCZdfrbTQLB4ZJOEoSVEnDgdpxg02Sp=K-vSfaxYJpKxnpGgw@mail.gmail.com> In-Reply-To: <CANCZdfoB6oJXF%2BCOt0071DKrc6fZ67V4jpm_5uTfjfnDchy2Ng@mail.gmail.com> References: <737703f2-26a6-4a84-a64b-3fa55cad721c@FreeBSD.org> <20240131204355.9EA2B19F@slippy.cwsent.com> <CANCZdfqVe%2BMGM846HPnMdHP=hhy6mKK2VHagzZ9R9p4C7JZgXA@mail.gmail.com> <CANCZdfrs%2BHZnvPz4pXhLxtd_kA_yUoUMRvrvzbQGJumEgrPmQg@mail.gmail.com> <CANCZdfoB6oJXF%2BCOt0071DKrc6fZ67V4jpm_5uTfjfnDchy2Ng@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <imp@bsdimp.com> wrote: > > > On Mon, Feb 5, 2024 at 8:34=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote= : > >> >> >> On Wed, Jan 31, 2024 at 1:59=E2=80=AFPM Warner Losh <imp@bsdimp.com> wro= te: >> >>> >>> >>> On Wed, Jan 31, 2024, 1:44=E2=80=AFPM Cy Schubert <Cy.Schubert@cschuber= t.com> >>> 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 <Cy.Schubert@cschubert.com> >>>> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org >>>> NTP: <cy@nwtime.org> Web: https://nwtime.org >>>> >>>> e^(i*pi)+1=3D0 >>>> >>>> >>>> --000000000000c66e3d0610ab7a3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 5, 2024 at 8:55=E2=80=AFA= M Warner Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= =3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Mon, Feb 5, 2024 at 8:34=E2=80=AFAM Warner= Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.co= m</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin= :0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= ><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"= ><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 31, 2024 at 1:59=E2=80= =AFPM Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_blank">i= mp@bsdimp.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex"><div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div= dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 31, 2024, 1:44=E2=80=AFPM Cy = Schubert <<a href=3D"mailto:Cy.Schubert@cschubert.com" target=3D"_blank"= >Cy.Schubert@cschubert.com</a>> wrote:<br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,204);padding-left:1ex">In message <737703f2-26a6-4a84-a64b-3fa55cad72= 1c@FreeBSD.org>, Andriy Gapon <br> wri<br> tes:<br> > On 31/01/2024 19:40, Cy Schubert wrote:<br> > > In message <04c4a0e1-aa79-4d25-a1f7-2196cfa65578@FreeBSD.org&g= t;, Jung-uk Kim<br> > > writ<br> > > es:<br> > >> On 24. 1. 31., Baptiste Daroussin wrote:<br> > >>> Hello,<br> > >>><br> > >>> Either this one or the previous import is breaking arm64 = build<br> > >>><br> > >>> --- acpi_iort.o ---<br> > >>> /home/bapt/worktrees/main/sys/arm64/acpica/acpi_iort.c:10= 3:4: error: fiel<br> > d<br> > >>> 'data' with variable sized type 'union (unnam= ed union at<br> > >>> /home/bapt/worktrees/main/sys/arm64/acpica/acpi_iort.c:98= :2<br> > >>> )' not at the end of a struct or class is a GNU exten= sion<br> > >>> [-Werror,-Wgnu-variable-sized-type-not-at-end]<br> > >>>=C2=A0 =C2=A0 =C2=A0103 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0} data;<br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0^<br> > >><br> > >> Sorry for the breakage.=C2=A0 I will fix it soon.<br> > >><br> > >> BTW, this code was added by this:<br> > >><br> > >> <a href=3D"https://reviews.freebsd.org/D31267" rel=3D"norefer= rer noreferrer" target=3D"_blank">https://reviews.freebsd.org/D31267</a><br= > > >><br> > >> It seems struct iort_named_component was a hack, which duplic= ated<br> > >> ACPI_IORT_NAMED_COMPONENT but with a fixed length field Devic= eName[32].<br> > >> Is it really necessary?<br> > > <br> > > Though they incorporated the WOL patch I've been using, they&= #39;ve broken<br> > > poweroff.<br> ><br> > The poweroff issue could be because of 9cdf326b4f<br> <br> Thanks. I clued into that a while ago after taking a break to read the ML.<= br> <br> This smelled of the original WOL problem I had last year that required <br> pulling the plug to allow the NIC to see the magic packet, but worse. Hence= <br> I was barking up the wrong tree.<br></blockquote></div></div><div dir=3D"au= to"><br></div><div dir=3D"auto">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?</div></div></blockquote><div><br></div><div>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</div><div>are all in files we don't user or= have deleted).</div></div></div></blockquote><div><br></div><div>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...<br></div><d= iv><br></div><div>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.</div></div></di= v></blockquote><div><br></div><div>I've merged the merge commit with th= e one fixup.</div><div><br></div><div>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:</div><div>=C2=A0347 files changed, 2891 insertio= ns(+), 1700 deletions(-)</div><div>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><div><br></div><= div>Warner<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div> <br></div= ><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border= -left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cl= ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div = dir=3D"auto"><div dir=3D"auto">Warner</div><div dir=3D"auto"><div class=3D"= gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> -- <br> Cheers,<br> Cy Schubert <<a href=3D"mailto:Cy.Schubert@cschubert.com" rel=3D"norefer= rer" target=3D"_blank">Cy.Schubert@cschubert.com</a>><br> FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 <a href= =3D"https://FreeBSD.org" rel=3D"noreferrer noreferrer" target=3D"_blank">ht= tps://FreeBSD.org</a><br> NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<a href=3D"mailto:cy@nwtim= e.org" rel=3D"noreferrer" target=3D"_blank">cy@nwtime.org</a>>=C2=A0 =C2= =A0 Web:=C2=A0 <a href=3D"https://nwtime.org" rel=3D"noreferrer noreferrer"= target=3D"_blank">https://nwtime.org</a><br>; <br> =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<br> <br> <br> </blockquote></div></div></div> </blockquote></div></div> </blockquote></div></div> </blockquote></div></div> --000000000000c66e3d0610ab7a3a--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrbTQLB4ZJOEoSVEnDgdpxg02Sp=K-vSfaxYJpKxnpGgw>