Hi Tom, On Thu, 31 Oct 2024 at 16:38, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, Oct 31, 2024 at 11:30:58PM +0100, Heinrich Schuchardt wrote: > > > > > > Am 31. Oktober 2024 19:01:47 MEZ schrieb Simon Glass <s...@chromium.org>: > > >Hi Heinrich, > > > > > >On Tue, 29 Oct 2024 at 23:32, Heinrich Schuchardt <xypron.g...@gmx.de> > > >wrote: > > >> > > >> > > >> > > >> Am 28. Oktober 2024 13:48:01 MEZ schrieb Simon Glass <s...@chromium.org>: > > >> >The current logging system suffers from some disadvantages, mainly that > > >> >it writes its output to the console and cannot be easily reviewed. > > >> > > > >> >Add a dedicated log, storing records in a binary format and including > > >> >the result codes and any return values from each call. The log is built > > >> >sequentially in memory and can be reviewed after any EFI operation. It > > >> >could potentially be written to media for later review, but that is not > > >> >implemented so far. > > >> > > >> An EFI specific solution is not a good approach as it does not scale to > > >> other parts of the code. Please, implement a log driver to collect the > > >> messages that you are interested in. > > >> > > > > > >I can do that too, but it isn't as easy to programmatically parse. I'd > > >like to track what calls are made and understand better what is going > > >on when Ubuntu boots, etc. > > > > What makes calls to log_debug hard to parse? We have __FILE__, __LINE__, > > __func__, and message text available as individual fields. > > > > What information are you missing? > > > > For tracking function calls we already have a trace capability in U-Boot. > > Integrating EFI_LOADER with existing U-Boot logging / tracing > infrastructure sounds like a reasonable path forward to me.
Yes, we already have that. I replied to Ilias' response elsewhere. Regards, Simon
