Re: [External] : Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification

[Alec Brown <alec.r.brown@xxxxxxxxxx>]

On Tue, Sep 21, 2021 at 03:07:25PM -0700, Julius Werner wrote:
> > Since it doesn't seem possible to have each boot component using the same 
> > log
> > format, we added a log_format and log_phys_addr fields to give flexibility 
> > in
> > how logs are stored. An example of a different log format that can be used 
> > is
> > the cbmem_console log format used by coreboot:
> 
> I am not exactly sure how you expect this interoperability you seem to
> be suggesting here to work. Are you saying that your bf_log_header can
> sometimes point to the bf_log_buffer structure you define, and
> sometimes to a coreboot CBMEM console buffer? But that's a completely
> different format that requires a different reader implementation, how
> is that supposed to work? If this proposal is just "we define a
> wrapper structure that points to everyone's custom firmware log
> implementation", then I don't really see the point (the only benefit
> still left then might be discovery of the log buffer, but that's the
> part you leave open in your design while all those other
> implementations already have working discovery mechanisms of their own
> anyway).
>

Depending on the preferred logging format by the boot component, bf_log_header
can point to our bf_log_buffer, a Coreboot CBMEM console buffer, or some other
preferred logging format. We are looking at ways to pass all logs through one
mechanism to make it simpler to discover all logs along the boot chain. From our
understanding, the CBMEM console is passed to the OS via a CBMEM table stored in
lower memory in a forwarding entry and is discovered by a user space tool
looking through /dev/mem. Is this correct? We aren't entirely sure how other
implementations of log buffers accomplish this, but we think that an explicit
mechanism can be beneficial. This is something we'll need to expand upon in the
specification.
 
> For the other structures you have defined, the same feedback that I
> think was already mentioned on the last iteration of this thread still
> applies: it seems incredibly bloated for a simple firmware logging
> mechanism. You have a whooping 24+n bytes of overhead *per line* which
> probably comes out to somewhere between 30-50% of total space wasted
> on overhead for the average log buffer. I guess there are just
> fundamentally different opinions on how featureful a firmware log
> mechanism needs to be so we're probably not gonna find a format that
> makes everyone happy here, but at least for the coreboot project I see
> little reason for us to implement something like this when we already
> have a well-working existing solution with tooling and wideranged
> support.

Since, the logging format we are proposing won't be the best for each boot
component environment, we are giving the option for boot components to use other
logging formats that best suits their environment.