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
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
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
oss.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 different firmw
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
On 16/11/2020 08.02, Ulrich Windl wrote:
Daniel Kiper schrieb am 14.11.2020 um 00:52 in
> Nachricht <20201113235242.k6fzlwmwm2xqh...@tomti.i.net-space.pl>:
> ...
>> The members of struct bf_log_msg:
>> ‑ size: total size of bf_log_msg struct,
>> ‑ ts_nsec: timestamp expressed in
>>> Daniel Kiper schrieb am 14.11.2020 um 00:52 in
Nachricht <20201113235242.k6fzlwmwm2xqh...@tomti.i.net-space.pl>:
...
> The members of struct bf_log_msg:
> ‑ size: total size of bf_log_msg struct,
> ‑ ts_nsec: timestamp expressed in nanoseconds starting from 0,
Who or what defines t == 0?
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
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 until now.
The goal is to pass all logs produced
13 matches
Mail list logo
