From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6D7CE2119C8AC for ; Mon, 7 Jan 2019 10:29:53 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B1F3888E57; Mon, 7 Jan 2019 18:29:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-126-62.rdu2.redhat.com [10.10.126.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id C040461B9D; Mon, 7 Jan 2019 18:29:48 +0000 (UTC) To: Leif Lindholm , AKASHI Takahiro Cc: Alexander Graf , Heinrich Schuchardt , trini@konsulko.com, robdclark@gmail.com, u-boot@lists.denx.de, edk2-devel@lists.01.org, Jian J Wang , Hao Wu , Ruiyu Ni , Star Zeng , Andrew Fish , Michael D Kinney , Ard Biesheuvel References: <20181214101043.14067-1-takahiro.akashi@linaro.org> <20181214101043.14067-3-takahiro.akashi@linaro.org> <20181217011626.GC14562@linaro.org> <84b6f3fd-ed68-a541-7727-69e5392984e6@suse.de> <20181225083024.GC14405@linaro.org> <20190107140932.uefkly3a3jzlyjjf@bivouac.eciton.net> From: Laszlo Ersek Message-ID: <7d6fbbff-ca48-588a-6082-bf8b95a7e829@redhat.com> Date: Mon, 7 Jan 2019 19:29:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190107140932.uefkly3a3jzlyjjf@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 07 Jan 2019 18:29:53 +0000 (UTC) Subject: Re: [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 18:29:53 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/07/19 15:09, Leif Lindholm wrote: > Apologies for late reply, back from holidays today. > I'm going to snip a whole lot of context below, since I have no idea what project this is about, and/or what files in that project (no diff hunk headers in the context). Judged from the address list, is this about u-boot perhaps? And adding type definitions to u-boot so they conform to the UEFI spec, and (assuming this "and" is possible) match edk2 practice? > My understanding is this: > - The EDK2 implementation does not conform to the specification; it > completely packs the EFI_HII_KEYBOARD_LAYOUT, which the > specification does not mention anything about. Since this code is > well in the wild, and drivers tested against the current layout need > to continuw eorking, I expect the only possible solution is to > update the specification to say EFI_HII_KEYBOARD_LAYOUT must be > packed. I'm going to take a pass on this. :) > - The default EDK2 definition of GUID (and hence EFI_GUID) gives it a > 32-bit alignment requirement also on 64-bit architectures. In > practice, I expect this would only affect (some of the) GUIDs that > are members of structs used in UEFI interfaces. But that may already > be too common an occurrence to audit and address in EDK2. Does the > spec need to change on this also? The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned, unless specified otherwise. See in "Table 5. Common UEFI Data Types": EFI_GUID -- 128-bit buffer containing a unique identifier value. Unless otherwise specified, aligned on a 64-bit boundary. Whether edk2 satisfies that, and if so, how (by chance / by general build flags), I don't know. The code says, /// /// 128 bit buffer containing a unique identifier value. /// Unless otherwise specified, aligned on a 64 bit boundary. /// typedef struct { UINT32 Data1; UINT16 Data2; UINT16 Data3; UINT8 Data4[8]; } GUID; I think there may have been an expectation in "MdePkg/Include/Base.h" that the supported compilers would automatically ensure the specified alignment, given the structure definition. Thanks Laszlo