Hi Tom,
On Fri, 11 Oct 2024 at 19:20, Tom Rini trini@konsulko.com wrote:
On Fri, Oct 11, 2024 at 03:21:22PM -0600, 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.
The other comments made in v3 about another project (EDKII) is that we want to remain implementation compatible. This is a case where (a) if needed, we can reach out and get the spec clarified to say zeroed memory and (b) even if it's not, this is a case where real world interoperability is more important than strict spec compliance. If there's an app out there relying on the zeroed behavior and it's fine on EDKII and not fine on us, it'll be a problem for us because we stopped matching behavior. So unless in the end Heinrich and/or Ilias drop their previous objection, I don't think this is a good idea.
This is a minor point, so I don't mind, so long as we get the memory-reservation tidied up. But I'll note that the effect of this patch is zero, since every allocated byte is written anyway, by current users.
I certainly don't want to be implementation-compatible with EDKII. Where did that come from? U-Boot is an open-source bootloader with lots of boards supported in mainline. U-Boot has very different goals and users.
Regards, Simon