[PATCH v4 4/9] efi: Drop the memset() from efi_alloc()

[Simon Glass]

Hi Heinrich,

On Sun, 3 Nov 2024 at 01:54, Heinrich Schuchardt <xypron.glpk at 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/5284a662181ff4b81dd19d1279aedb68725b827f/edk2misc.c#L215
>
> 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