[edk2-devel] [RFC] Expose HII package list via C variables

Michael D Kinney michael.d.kinney at intel.com
Wed Aug 25 22:33:48 UTC 2021


Hi Marvin,

I think this feature is already there and supported.

HII can either be in a global variable or in a PE/COFF resource section.
The default is a global variable because HII was implemented before the
PE/COFF resource section feature was added to the UEFI Specification.

There is an INF [Defines] section statement to enable the PE/COFF
section. See UefiHiiResource in the following link.

https://tianocore-docs.github.io/edk2-InfSpecification/draft/3_edk_ii_inf_file_format/34_[defines]_section.html#34-defines-section

How is your proposal different than this existing capability?

Thanks,

Mike

> -----Original Message-----
> From: devel at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Marvin Häuser
> Sent: Wednesday, August 25, 2021 2:21 PM
> To: devel at edk2.groups.io
> Cc: Andrew Fish <afish at apple.com>; leif at nuviainc.com; Kinney, Michael D <michael.d.kinney at intel.com>; Ni, Ray
> <ray.ni at intel.com>; Gao, Zhichao <zhichao.gao at intel.com>; Wang, Jian J <jian.j.wang at intel.com>; Wu, Hao A
> <hao.a.wu at intel.com>; Bi, Dandan <dandan.bi at intel.com>; Dong, Eric <eric.dong at intel.com>; Bret Barkelew
> <Bret.Barkelew at microsoft.com>; Vitaly Cheptsov <vit9696 at protonmail.com>
> Subject: [edk2-devel] [RFC] Expose HII package list via C variables
> 
> Good day everyone,
> 
> Currently, the HII package list is stored in a PE/COFF resource section
> [1]. I propose to store it in a C variable (byte array with a pointer to
> it and its size exposed) instead. DxeCore would have a guard to toggle
> the deprecated support for the automatic protocol installation. This has
> the following advantages:
> 
> 1. Fixes BZ (incl. future toolchains):
> https://bugzilla.tianocore.org/show_bug.cgi?id=557
> 2. Universal method across all toolchains and output file formats
> 3. Saves error-prone parsing work
> 4. Saves protocol install/locate work, the data is available right away
> 5. The omission of a dedicated section can save space
> 6. Terse file formats can support this and remain terse :)
> 7. Removes a dependency on the PE/COFF format specifically
> 
> A *very rough* PoC diff can be found here:
> https://github.com/mhaeuser/edk2/compare/master...wip_hii_cvar
> If the feedback is positive, I will clean it up of course. OVMF boots
> with everything working fine.
> 
> I'd explicitly like feedback on the following:
> A. Is this an acceptable solution to BZ 557 (Andrew?)?
> B. Is this an acceptable solution for the "HII workflow" (MdeModule
> maintainers?)?
> C. Is it acceptable to make support UEFI-side support for the old
> mechanism optional (Stewards?)?
> D. Can an acceptable alternative be found for the removed ShellPkg code
> (Shell maintainers?)?
> 
> As you can see the BaseTools part also is rough, but that is more a
> question of "how" rather than "whether", so I'll postpone asking about it.
> 
> Thanks for your time and feedback!
> 
> Best regards,
> Marvin
> 
> 
> [1] "Once the image is loaded, LoadImage() installs
> EFI_HII_PACKAGE_LIST_PROTOCOL on the handle if
> the image contains a custom PE/COFF resource with the type 'HII'."
> - UEFI 2.9, 7.4, "EFI_BOOT_SERVICES.LoadImage()"
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79808): https://edk2.groups.io/g/devel/message/79808
Mute This Topic: https://groups.io/mt/85147044/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-






More information about the edk2-devel-archive mailing list