All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>,
	Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	Patrick Delaunay <patrick.delaunay@foss.st.com>,
	U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH 6/8] cmd: efidebug: simplify printing GUIDs
Date: Tue, 25 Jan 2022 09:19:32 +0900	[thread overview]
Message-ID: <20220125001932.GA9031@laputa> (raw)
In-Reply-To: <770c7f69-af81-6123-ae69-e399d6e3e67d@gmx.de>

On Mon, Jan 24, 2022 at 09:25:34AM +0100, Heinrich Schuchardt wrote:
> On 1/24/22 08:23, AKASHI Takahiro wrote:
> > On Fri, Jan 21, 2022 at 05:03:03PM +0100, Heinrich Schuchardt wrote:
> > > On 1/21/22 16:20, Simon Glass wrote:
> > > > Hi Heinrich,
> > > > 
> > > > On Sun, 16 Jan 2022 at 08:14, Heinrich Schuchardt
> > > > <heinrich.schuchardt@canonical.com> wrote:
> > > > > 
> > > > > Use "%pS" to print text representations of GUIDs.
> > > > > 
> > > > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > > > ---
> > > > >    cmd/efidebug.c         | 160 ++---------------------------------------
> > > > >    include/efi_api.h      |   8 +++
> > > > >    include/efi_dt_fixup.h |   4 --
> > > > >    include/efi_rng.h      |   4 --
> > > > >    lib/uuid.c             | 116 ++++++++++++++++++++++++++++++
> > > > >    5 files changed, 128 insertions(+), 164 deletions(-)
> > > > > 
> > > > 
> > > > Does this blow up the image size? These strings only in the debug side before.
> > > 
> > > It was to avoid image size increase that I added
> > > +#ifdef CONFIG_CMD_EFIDEBUG
> > > 
> > > > 
> > > > Having said that, I would much rather see a string than a guid, which
> > > > I consider to be little more than an obfuscation.
> > > 
> > > That was my motivation. When debugging a boot failure I set DEBUG in
> > > lib/efi_loader/efi_boottime.c and reading GUIDs in the debug output was not
> > > helpful.
> > 
> > But setting DEBUG in efi_boottime.c doesn't lead to CONFIG_CMD_EFIDEBUG
> > being on in uuid.c. Do we want to have a more direct CONFIG?
> 
> We could use CONFIG_LOGLEVEL >= LOGL_DEBUG because once that loglevel is
> set you can use the log command to log one of the EFI related functions.

I'm not sure the log level is the best choice for controlling messages.
Showing a human-readable GUID would also be a help in case of errors.

> Overall the EFI debugging requires rethinking:

I definitely agree, no specific idea though.

-Takahiro Akashi

> If you simply add '#define DEFINE 1' to the top of
> lib/efi_loader/efi_boottime your screen will be flooded by function
> calls related to timer events. Probably those high frequency events
> should use LOGL_DEBUG_IO.
> 
> Best regards
> 
> Heinrich
> 
> > 
> > -Takahiro Akashi
> > 
> > > Best regards
> > > 
> > > Heinrich
> > > 
> > > > 
> > > > Regards,
> > > > Simon
> 

  reply	other threads:[~2022-01-25  0:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-16 15:14 [PATCH 0/8] efi_loader: simplify printing GUIDs Heinrich Schuchardt
2022-01-16 15:14 ` [PATCH 1/8] lib: compile uuid_guid_get_str if CONFIG_LIB_UUID=y Heinrich Schuchardt
2022-01-21 15:20   ` Simon Glass
2022-01-16 15:14 ` [PATCH 2/8] lib: printf code %pUs for GUID text representation Heinrich Schuchardt
2022-01-18  2:48   ` AKASHI Takahiro
2022-01-16 15:14 ` [PATCH 3/8] disk: simplify part_print_efi() Heinrich Schuchardt
2022-01-21 15:20   ` Simon Glass
2022-01-16 15:14 ` [PATCH 4/8] sandbox: imply PARTITION_TYPE_GUID Heinrich Schuchardt
2022-01-21 15:20   ` Simon Glass
2022-01-16 15:14 ` [PATCH 5/8] test: add test for %pUs Heinrich Schuchardt
2022-01-21 15:20   ` Simon Glass
2022-01-16 15:14 ` [PATCH 6/8] cmd: efidebug: simplify printing GUIDs Heinrich Schuchardt
2022-01-21 15:20   ` Simon Glass
2022-01-21 16:03     ` Heinrich Schuchardt
2022-01-21 16:53       ` Simon Glass
2022-01-24  7:23       ` AKASHI Takahiro
2022-01-24  8:25         ` Heinrich Schuchardt
2022-01-25  0:19           ` AKASHI Takahiro [this message]
2022-01-16 15:14 ` [PATCH 7/8] efi_loader: user %pUs for " Heinrich Schuchardt
2022-01-21 15:20   ` Simon Glass
2022-01-16 15:14 ` [PATCH 8/8] cmd: printenv: simplify " Heinrich Schuchardt

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-all 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=20220125001932.GA9031@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=patrick.delaunay@foss.st.com \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.