hi Simon,
On Thu, 1 Aug 2024 at 19:14, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Thu, 1 Aug 2024 at 04:14, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Tom
On Wed, 31 Jul 2024 at 20:17, Tom Rini trini@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
You need to define 'the app' a bit better. An app for example may load, use efi_allocate_pool to inject some runtime memory data which the OS expects and exit. The you would load you OS (which is really another EFI app). In general I wouldn't make any assumptions on what EFI apps will do wrt to memory
/Ilias
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