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

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.

Warner


> 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
>>>
>>>
>>>