From nobody Thu Feb 01 23:27:04 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 4TQw7d3C55z58vJh; Thu, 1 Feb 2024 23:28:13 +0000 (UTC) (envelope-from dsl@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQw7d2NSFz4sk3; Thu, 1 Feb 2024 23:28:13 +0000 (UTC) (envelope-from dsl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706830093; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eJPV52JB8M2A9LaZnEbqlYPkkXVOL1iFYr7FSHJ4Saw=; b=GGoYTqOVxKBJPM8mPppZVLz1s1et8z7w/zX+nElFTEJUC19cEb9Hr0OZGO/t5U0kj1skNT PRblsimBbjOeEkV/fAvIP7BJ83Q9f5pU/vvY8/Fp0qgezDMGOsvLFpn2BjZLIkqaC+A40b fuZgDbmhvWrmdpKXZNLd+M/3wfjYR/py0oka6TiqZGEkp/2bK0cMpvTDMiHxiHL7kwBHzr vo8blgS0ZirO7Y75/NAwr7jDgIj3VD6k9zKqD0JRv5dA3anNGgjrBeUFGhyWB9ezGibvmf tkChodBgas54yj6OqQ1h8Va2IBCe3YA9gwj2m6gzdU34d1TeQNl3auOZVXZ0UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706830093; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eJPV52JB8M2A9LaZnEbqlYPkkXVOL1iFYr7FSHJ4Saw=; b=sxQ++txb5gW3aCZRPzIqjIoh6LVLkhXGSuwO2V3o1LzwOMgnNQtuFn6k7rF9D9BDd/AwnD C37e2fCnp+DtFNyVDifRGrPV542esaLApYouGn5A3druMaH9stSOB50vScc6ADvCffbbSb 4QqiUPMCyNEhcgrCoHQQvD5RUtxeMZ3Oouszj+FVUayZL37CUn8iIRk8CFbegckQmB9kMm AdjEIBivf1GUT4Li0ddq+FISrl1SbmEFsGVTSdTawLAcL+wxv1RYvE3aHwghxLUI2SfHuR PCiOc6lyAbRsymI6ewQrNjjLYUh5QK/yfHDADi1wok5bRNeVg+wrA+GyHRwu9A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706830093; a=rsa-sha256; cv=none; b=CjsbLZiZd2K3vo2+5rDxH2C0YJ0L+rI4xPmVkHUp9vWYvfgiNNszwirK8dyoigx6Z9X8IX +tbjZpox3hXd0v9zN4qCysJeiD/Kspp36Vdpzb7wHaoC/dcovyPyLtrUgcKrOUE7le9qg1 /Rs8xIGvBkMlxRjIH1O6bkcIv4r9JadRnFyvqAjs7WO2DNkwnlmnVHbr9Yh0EGWcA/+iIc dXU334vV1e5O1NTnoFZZLgtIX2/IsJmHYMy87lvSav9gArMVvkSmhe7Ys/VnrZgKghF7zj x1iDwj+yU0xCzQ4dx8QRl8iE6Hf1Y36yXhgQvtQQ+Z0uoAft+uY3DZoFcYikvw== Received: from localhost (unknown [91.226.51.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: dsl) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TQw7c6NzbzLHR; Thu, 1 Feb 2024 23:28:12 +0000 (UTC) (envelope-from dsl@FreeBSD.org) References: <202401310406.40V46B9a000876@gitrepo.freebsd.org> <04c4a0e1-aa79-4d25-a1f7-2196cfa65578@FreeBSD.org> <86o7cz99u6.fsf@peasant.tower.home> User-agent: mu4e 1.8.13; emacs 29.1 From: Dmitry Salychev To: Jung-uk Kim Cc: Baptiste Daroussin , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 07c64d74917e - main - acpica: Import ACPICA 20230628 Date: Fri, 02 Feb 2024 00:27:04 +0100 In-reply-to: Message-ID: <86jznn933q.fsf@peasant.tower.home> 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 Content-Type: text/plain Jung-uk Kim writes: > On 24. 2. 1., Dmitry Salychev wrote: >> Hi, >> Jung-uk Kim writes: >> >>> 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: field >>>> '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? >>> >>> Jung-uk Kim >> I'm struggling to understand (a) how the entire anonymous "data" >> union >> was added by https://reviews.freebsd.org/D31267 as was "named_comp" >> only and (b) what the problem with the "struct iort_named_component" really >> is as ACPI_IORT_ROOT_COMPLEX and ACPI_IORT_SMMU were re-defined as >> incomplete types in the new version of ACPICA. Everything is compilable >> as it used to be with the attached patch. > > FYI, ACPICA 20230331 dropped support for ANSI C (C89) and minimum > requirement is C99 now. One of the first feature they used was the > variable-length array, which replaced "foo[1]" hack. Previously, > "sizeof(struct bar)" was not real size because of the (fake > variable-length) array at the end of it. Now they removed the hack > and started using real variable-length arrays. I believe the hack in > acpi_iort.c was to work around the fake 1-byte array but it does not > work any more because all ACPI_IORT_* are now using correct VLA. So, > the cleanest way to fix this is using ACPI_IORT_NAMED_COMPONENT > instead of "struct iort_named_component" (see attached PoC patch), > which also eliminates the need for DeviceName[32]. > > Jung-uk Kim > > [2. text/x-patch; iort.diff]... Please, open a review for your patch. I've several questions. Regards, Dmitry -- https://wiki.freebsd.org/DmitrySalychev