public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Samer El-Haj-Mahmoud" <samer.el-haj-mahmoud@arm.com>
To: Leif Lindholm <leif@nuviainc.com>, Ard Biesheuvel <ardb@kernel.org>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Pete Batard <pete@akeo.ie>,
	Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Subject: Re: [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity
Date: Sat, 20 Feb 2021 23:25:20 +0000	[thread overview]
Message-ID: <DB7PR08MB326001710D2A1C5353A65E2E90839@DB7PR08MB3260.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20210220214614.GL1664@vanye>

Leif,

I admit, this is not *super* annoying on a normal DEBUG build boot. On the RPi4 for instance, this shows up between 25-50 times until the OS boots (depending on the boot source).

On a test run (such as running SCT), this message is *EXTREMLY* annoying. I see ~6600 instances on one run, accounting for ~60% of the entire debug output during the test. I agree we should not be optimizing for a test run, but this is just beyond being reasonable..

How useful is this message in non-verbose DEBUG output? Does it need to be repeated for every call to LibGetTime() ? I am open for suggestions on rate limiting the output.

--Samer

> -----Original Message-----
> From: Leif Lindholm <leif@nuviainc.com>
> Sent: Saturday, February 20, 2021 4:46 PM
> To: Ard Biesheuvel <ardb@kernel.org>
> Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>;
> devel@edk2.groups.io; Ard Biesheuvel <ardb+tianocore@kernel.org>; Pete
> Batard <pete@akeo.ie>
> Subject: Re: [edk2-platform][PATCH v1 1/1]
> EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity
>
> *How* annoying was this?
>
> This is kind of useful information, well at the "would be good to see in a
> regular DEBUG build" level.
>
> This change will have suddenly effectively hidden a message that was already
> present in many platforms, where they were not (very) annoyingly repetitive
> during a normal boot.
>
> It feels the test suite is not the thing that we need to optimise debug output
> for.
>
> Is there some alternative way we can rate limit this?
>
> /
>     Leif
>
> On Sat, Feb 20, 2021 at 17:50:43 +0100, Ard Biesheuvel wrote:
> > On Sat, 20 Feb 2021 at 17:41, Samer El-Haj-Mahmoud
> > <Samer.El-Haj-Mahmoud@arm.com> wrote:
> > >
> > > the DEBUG message for using compilation time epoch is appearing very
> > > frequently on DEBUG firmware builds, for example during UEFI SCT runs.
> > > Reduce verbosity to avoid the annoying repetitive message.
> > >
> > > Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
> > > Cc: Leif Lindholm <leif@nuviainc.com>
> > > Cc: Pete Batard <pete@akeo.ie>
> > > Signed-off-by: Samer El-Haj-Mahmoud <Samer.El-Haj-
> Mahmoud@arm.com>
> >
> >
> > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> >
> > Merged as #1434 into master.
> >
> > > ---
> > >
> > > EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.
> > > c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLi
> > > b.c
> > > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLi
> > > b.c index 5c13ed4cf190..4210708cff36 100644
> > > ---
> > > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLi
> > > b.c
> > > +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClo
> > > +++ ckLib.c
> > > @@ -88,7 +88,7 @@ LibGetTime (
> > >      //
> > >      EpochSeconds = BUILD_EPOCH;
> > >      DEBUG ((
> > > -      DEBUG_INFO,
> > > +      DEBUG_VERBOSE,
> > >        "LibGetTime: %s non volatile variable was not found - Using
> compilation time epoch.\n",
> > >        mEpochVariableName
> > >        ));
> > > --
> > > 2.25.1
> > >
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

  reply	other threads:[~2021-02-20 23:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-20 16:41 [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity Samer El-Haj-Mahmoud
2021-02-20 16:50 ` Ard Biesheuvel
2021-02-20 17:22   ` [edk2-devel] " Samer El-Haj-Mahmoud
2021-02-20 21:46   ` Leif Lindholm
2021-02-20 23:25     ` Samer El-Haj-Mahmoud [this message]
2021-02-21 10:50     ` Ard Biesheuvel
2021-02-21 20:43       ` Leif Lindholm
2021-02-21 20:50         ` Ard Biesheuvel
2021-02-21 21:33           ` Leif Lindholm
  -- strict thread matches above, loose matches on Subject: below --
2020-12-20 19:07 Samer El-Haj-Mahmoud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB7PR08MB326001710D2A1C5353A65E2E90839@DB7PR08MB3260.eurprd08.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox