hi Simon, On Thu, 1 Aug 2024 at 19:14, Simon Glass <s...@chromium.org> wrote: > > Hi Ilias, > > On Thu, 1 Aug 2024 at 04:14, Ilias Apalodimas > <ilias.apalodi...@linaro.org> wrote: > > > > Hi Tom > > > > On Wed, 31 Jul 2024 at 20:17, Tom Rini <tr...@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
