Date:   Tue, 21 Sep 2021 15:07:25 -0700
From:   Julius Werner <jwerner@...omium.org>
To:     Alec Brown <alec.r.brown@...cle.com>
Cc:     "coreboot@...eboot.org" <coreboot@...eboot.org>,
        "grub-devel@....org" <grub-devel@....org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "systemd-devel@...ts.freedesktop.org" 
        <systemd-devel@...ts.freedesktop.org>,
        "trenchboot-devel@...glegroups.com" 
        <trenchboot-devel@...glegroups.com>,
        "u-boot@...ts.denx.de" <u-boot@...ts.denx.de>,
        "x86@...nel.org" <x86@...nel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        Aleksandr Burmashev <alexander.burmashev@...cle.com>,
        "allen.cryptic@...il.com" <allen.cryptic@...il.com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "btrotter@...il.com" <btrotter@...il.com>,
        Daniel Kiper <daniel.kiper@...cle.com>,
        "dpsmith@...rtussolutions.com" <dpsmith@...rtussolutions.com>,
        Eric DeVolder <eric.devolder@...cle.com>,
        Eric Snowberg <eric.snowberg@...cle.com>,
        "frowand.list@...il.com" <frowand.list@...il.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "hun@...imensional.de" <hun@...imensional.de>,
        "james.dutton@...il.com" <james.dutton@...il.com>,
        "javierm@...hat.com" <javierm@...hat.com>,
        Joao Martins <joao.m.martins@...cle.com>,
        "jwerner@...omium.org" <jwerner@...omium.org>,
        Kanth Ghatraju <kanth.ghatraju@...cle.com>,
        Konrad Wilk <konrad.wilk@...cle.com>,
        "krystian.hebel@...eb.com" <krystian.hebel@...eb.com>,
        "leif@...iainc.com" <leif@...iainc.com>,
        "lukasz.hawrylko@...el.com" <lukasz.hawrylko@...el.com>,
        "luto@...capital.net" <luto@...capital.net>,
        "michal.zygowski@...eb.com" <michal.zygowski@...eb.com>,
        "mjg59@...gle.com" <mjg59@...gle.com>,
        "mtottenh@...mai.com" <mtottenh@...mai.com>,
        "nico.h@....de" <nico.h@....de>,
        "phcoder@...il.com" <phcoder@...il.com>,
        "piotr.krol@...eb.com" <piotr.krol@...eb.com>,
        "pjones@...hat.com" <pjones@...hat.com>,
        "pmenzel@...gen.mpg.de" <pmenzel@...gen.mpg.de>,
        "rasmus.villemoes@...vas.dk" <rasmus.villemoes@...vas.dk>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "roger.pau@...rix.com" <roger.pau@...rix.com>,
        Ross Philipson <ross.philipson@...cle.com>,
        "sjg@...omium.org" <sjg@...omium.org>,
        "trini@...sulko.com" <trini@...sulko.com>,
        "tyhicks@...ux.microsoft.com" <tyhicks@...ux.microsoft.com>,
        "ulrich.windl@...uni-regensburg.de" 
        <ulrich.windl@...uni-regensburg.de>,
        "wvervoorn@...an.com" <wvervoorn@...an.com>,
        "xypron.glpk@....de" <xypron.glpk@....de>,
        "rharwood@...hat.com" <rharwood@...hat.com>
Subject: Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification

> 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).

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.

Powered by blists - more mailing lists