[PATCH 5/6] efi: Use malloc() for the EFI pool
Simon Glass
sjg at chromium.org
Thu Aug 1 18:14:35 CEST 2024
Hi Ilias,
On Thu, 1 Aug 2024 at 04:14, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Hi Tom
>
> On Wed, 31 Jul 2024 at 20:17, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Jul 31, 2024 at 08:39:23AM -0600, Simon Glass wrote:
> >
> > [snip]
> > > > > > so that
> > > > > > step three can be seeing what tweaks may be needed in where things
> > > > > > allocate memory.
> > > > >
> > > > > So my series is step 3?
> > > >
> > > > Or at least understanding what the problems may still be, yes.
> > >
> > > In that case I would like to clean up EFI's memory management before
> > > doing step 2, since I believe many of the problems will just go away
> > > if we can get that right.
> >
> > Well, I think that's where some of the big points of contention are,
> > yes. You say "fix" and Ilias and Heinrich say "but the spec".
>
> Using malloc on efi_allocate_pool() would be ok spec-wise. Simon's
> current patch is ignoring the efi memory type metadata we have to
> preserve. On top of that using malloc for a *single* memory type, just
> kicks the can down the road until an EFI app chooses a different type
> and we are back to the same problem.
>
> It's fine to teach efi_allocate_pool to use malloc with 2 conditions
> - memory types are preserved for all allocations
> - malloc area is big enough
OK thanks I will take a look.
I see the EFI code eventually dealing with memory in two distinct phases:
- before the app runs: we try to keep memory usage to within areas people expect
- once the app runs: t doesn't matter anymore
>
> Cheers
> /Ilias
>
> >
> > Perhaps once step one is done it will be easier to find a way to address
> > your concerns without also breaking "the spec".
Regards,
Simon
More information about the U-Boot
mailing list