Hi,
On Wed, 20 Nov 2024 at 19:19, Simon Glass sjg@chromium.org wrote:
Hi,
On Wed, 20 Nov 2024 at 13:49, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 20. November 2024 19:06:33 MEZ schrieb Tom Rini trini@konsulko.com:
On Wed, Nov 20, 2024 at 05:55:18PM +0200, Ilias Apalodimas wrote:
Hi Simon,
On Wed, 20 Nov 2024 at 17:37, Simon Glass sjg@chromium.org wrote:
HI Ilias,
On Fri, 1 Nov 2024 at 05:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Thu, 31 Oct 2024 at 20:02, Simon Glass sjg@chromium.org wrote: > > Hi Ilias, > > On Tue, 29 Oct 2024 at 19:32, Ilias Apalodimas > ilias.apalodimas@linaro.org wrote: > > > > On Tue, 29 Oct 2024 at 17:45, Simon Glass sjg@chromium.org wrote: > > > > > > Hi Ilias, > > > > > > On Tue, 29 Oct 2024 at 10:58, Ilias Apalodimas > > > ilias.apalodimas@linaro.org wrote: > > > > > > > > Hi Simon, > > > > > > > > On Mon, 28 Oct 2024 at 14:48, Simon Glass sjg@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.
For the idea, no. But I don't think what's implemented here is what we want.
To track what EFI services are called, we already have EFI_ENTRY and EFI_EXIT. Why don't we instead, add a logging service (and we already have ftrace iirc) and plug it in the macros above? That would make more sense not to mention way less code.
I am wanting to programmatically log and manage what EFI_LOADER does, so that bootstd can present a high-level view of what is going on, e.g. which protocols are used, how much memory is allocated and where. So this is not just about logging text output.
Why the EFI_LOADER only? Bootstd is supposed to cover more cases, so why not a generic framework for all boot commands?
This feels similar to the point I've made elsewhere in this overarching series, why not do this at existing common points in the code path?
The common code point is the log library. Just add an event there for which the test can register a handler.
With a log event you get:
function name source location message class message text message priority
and all of this with minimal invasiveness.
OK guys, I think I got the message :-)
I'm going to apply this to my tree for now. While I'm at it I think it is time to go through my backlog and apply some other things that I'd like in there.
One point I didn't mention is that this series allows logging of all calls, not just the ones that come in from the app. At present there are quite a few efi_allocate_pages() calls which are entirely internal.
Regards, Simon