Hi Heinrich,
On Sun, 3 Nov 2024 at 01:54, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/3/24 01:28, Simon Glass wrote:
From my inspection none of the users need the memory to be zeroed. It is somewhat unexpected that it does so, since the name gives no clue to this.
Drop the memset() so that it effectively becomes a wrapper around the normal EFI-pool allocator.
Another option would be to drop this function and call efi_allocate_pool() directly, but that increase code size a little.
Move the function comment to the header file like most other exported functions in U-Boot.
Comments were made in v3 that another project uses memset() when allocating memory, but that is not required by the spec. In any case, as above, from inspection, none of the users need the memory to be zeroed, as they fill the entire region with their own data.
As already written in response to v3 of the series I want to be sure that code that runs on EDK II does not fail on U-Boot.
EFI_DEVICE_PATH_UTILITIES_PROTOCOL.CreateDeviceNode() in EDK II zeros out the returned buffer. We implement this function via efi_alloc().
Here is a code example relying on a zeroed out node:
https://github.com/acidanthera/gfxutil/blob/5284a662181ff4b81dd19d1279aedb68...
Please, drop the patch.
I have created issue USWG 0002487 https://mantis.uefi.org/mantis/view.php?id=2487) asking to indicate in the specification if the returned device path node should be zeroed out by the firmware.
OK thanks.
But please ignore this patch. The whole series was sent by mistake.
Regards, Simon