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.