[PATCH 00/15] efi_loader: Add support for logging to a buffer

[Simon Glass]

Hi Ilias,

On Tue, 29 Oct 2024 at 19:32, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> On Tue, 29 Oct 2024 at 17:45, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Ilias,
> >
> > On Tue, 29 Oct 2024 at 10:58, Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, 28 Oct 2024 at 14:48, Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > It is a bit of a pain to log EFI boot-services calls at present. The
> > > > output goes to the console so cannot easily be inspected later. Also it
> > > > would be useful to be able to store the log and review it later, perhaps
> > > > after something has gone wrong.
> > > >
> > > > This series makes a start on implementing a log-to-buffer feature. It
> > > > provides a simple 'efidebug log' command to inspect the buffer. For now,
> > > > only memory allocations are logged.
> > >
> > > Why is this problem specific to EFI and no U-Boot in general? Do we
> > > have a similar machinery for malloc()?
> >
> > Mostly because an app can make EFI calls and we want to know what they
> > are, e.g. to debug them and figure out what might be wrong when
> > something doesn't boot.
>
> EFI_PRINT() has been proven pretty useful for this. I don't personally
> see the point of adding ~1300 lines of code to replace a print.
> What would make more sense is teach EFI_PRINT to log errors in a buffer.

Is that a NAK? Please be clear if you are reviewing the code or just
rejecting the whole idea.

I am hoping to expand this into a debugging tool for figuring out how
to boot Windows and perhaps logging detailed information when things
go wrong, for later analysis. It might seem like overkill, but we will
see.

Regards,
Simon