Re: git: 07c64d74917e - main - acpica: Import ACPICA 20230628

On Mon, Feb 5, 2024 at 8:55 AM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Mon, Feb 5, 2024 at 8:34 AM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>>
>> On Wed, Jan 31, 2024 at 1:59 PM Warner Losh <imp@bsdimp.com> wrote:
>>
>>>
>>>
>>> On Wed, Jan 31, 2024, 1:44 PM Cy Schubert <Cy.Schubert@cschubert.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 included
> where it wasn't before. Once I make sure that world and kernel still build,
> I'll push the change since limits.h isn't going to affect any functionality
> 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 who
> 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=0
>>>>
>>>>
>>>>