[PATCH v4 1/5] efi: Drop the memset() from efi_alloc()

[Simon Glass]

Hi Tom,

On Fri, 11 Oct 2024 at 19:20, Tom Rini <trini at 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