Hi Daniel,
On Fri, 13 Nov 2020 at 19:07, Daniel Kiper wrote:
>
> Hey,
>
> This is next attempt to create firmware and bootloader log specification.
> Due to high interest among industry it is an extension to the initial
> bootloader log only specification. It takes into the account most of the
>
On 12/4/20 7:23 AM, Paul Menzel wrote:
> Dear Wim, dear Daniel,
>
>
> First, thank you for including all parties in the discussion.
> Am 04.12.20 um 13:52 schrieb Wim Vervoorn:
>
>> I agree with you. Using an existing standard is better than inventing
>> a new one in this case. I think using the
On Fri, Dec 04, 2020 at 02:23:23PM +0100, Paul Menzel wrote:
> Dear Wim, dear Daniel,
>
>
> First, thank you for including all parties in the discussion.
> Am 04.12.20 um 13:52 schrieb Wim Vervoorn:
>
> > I agree with you. Using an existing standard is better than inventing
> > a new one in this
Dear Wim, dear Daniel,
First, thank you for including all parties in the discussion.
Am 04.12.20 um 13:52 schrieb Wim Vervoorn:
I agree with you. Using an existing standard is better than inventing
a new one in this case. I think using the coreboot logging is a good
idea as there is indeed a l
rix.com; ross.philip...@oracle.com;
tyhi...@linux.microsoft.com; Heinrich Schuchardt
Subject: Re: [SPECIFICATION RFC] The firmware and bootloader log specification
Standardizing in-memory logging sounds like an interesting idea, especially
with regards to components that can run on top of diffe
On Sat, Nov 14, 2020 at 2:01 AM Daniel Kiper wrote:
...
> The log specification should be as much as possible platform agnostic
> and self contained. The final version of this spec should be merged into
> existing specifications, e.g. UEFI, ACPI, Multiboot2, or be a standalone
> spec, e.g. as a
Standardizing in-memory logging sounds like an interesting idea,
especially with regards to components that can run on top of different
firmware stacks (things like GRUB or TF-A). But I would be a bit wary
of creating a "new standard to rule them all" and then expecting all
projects to switch what
On 14.11.20 00:52, Daniel Kiper wrote:
> Hey,
>
> This is next attempt to create firmware and bootloader log specification.
> Due to high interest among industry it is an extension to the initial
> bootloader log only specification. It takes into the account most of the
> comments which I got up un
On Sat, 14 Nov 2020 at 12:37, Nico Huber wrote:
> > (I think
> > newer spec versions should not change anything in first 5 bf_log
> members;
> > this way older log parsers will be able to traverse/copy all logs
> regardless
> > of version used in one log or another),
>
> Good point, w
Hi Daniel,
I think this is a good idea. Alas, as I hear for the first time about
it, I lack any context of prior discussions / context. So bear with me,
if I ask things that have already been answered.
On 14.11.20 00:52, Daniel Kiper wrote:
> The goal is to pass all logs produced by various boot
On 11/13/20 3:52 PM, Daniel Kiper wrote:
> Hey,
>
>
> Here is the description (pseudocode) of the structures which will be
> used to store the log data.
>
> Anyway, I am aware that this is not specification per se.
Yes, you have caveats here. I'm sure that you either already know
or would lear
11 matches
Mail list logo
