All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: sjg@chromium.org, u-boot@lists.denx.de,
	ilias.apalodimas@linaro.org, Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH v6 12/12] test: efi: boot: Add a test for the efi bootmeth
Date: Tue, 15 Oct 2024 13:36:23 +0200	[thread overview]
Message-ID: <23757cf3-c27a-498d-9e66-59261f060102@gmx.de> (raw)
In-Reply-To: <87cyk1hdne.fsf@bloch.sibelius.xs4all.nl>

On 15.10.24 12:19, Mark Kettenis wrote:
>> Date: Mon, 14 Oct 2024 15:11:50 -0600
>> From: Tom Rini <trini@konsulko.com>
>>
>> On Mon, Oct 14, 2024 at 01:13:41PM -0600, Simon Glass wrote:
>>
>> [snip]
>>> Or perhaps just have a way to turn it off? I first sent this patch
>>> last November. It is just wrong to generate output like this which we
>>> don't want. There isn't even a test for it, so just add a way to
>>> disable it, and be done!
>>
>> I don't know that it's unwanted. As I'm trying to get Heinrich to
>> explain, _why_ does efi_setup_console_size need to exist, and do what it
>> does? This isn't the case of color-coding the output of tests as they
>> happen, there must be a reason we care about knowing the console size.
>> At that point we can figure out if the right answer is:
>> - Don't generate that check on serial ports, it's somewhere between
>>    misleading to wrong.
>> - text-based tests just need to expect and skip it because there's a
>>    good reason to need to know the console size and not just assume
>>    80x24.
>> - Something else we won't know until it's clearly explained why we do
>>    this.
>
> Sadly this is a misfeature of UEFI.  The EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL
> is required if console devices are supported by the UEFI
> implementation, and is built around the concept of "text mode" with a
> fixed number of character rows and columns.  That pretty much assumes
> there is some sort of terminal emulator on the other end.  And this is
> pretty much incompatible with anything that just want to log serial
> output.
>
> I think it is possible to do better though.  Instead of calling
> efi_setup_console_size() in efi_init_obj_list(), we could postpone
> this until the application makes a call that requires us to know the
> size.  This would mean that a simple EFI application that just uses
> EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString() (such as the Hello
> world EFI application or the OpenBSD EFI bootloader) wouldn't have to
> do the size query.

The implementation of EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString()
needs to know the output size to update the cursor position in

   EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.MODE.CursorColumn
   EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.MODE.CursorRow

The EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL is passed to the entry point of any
EFI application via the system table.

We could delay the invocation of efi_setup_console_size() to the launch
of the first EFI application (efi_start_image()).

Best regards

Heinrich

  reply	other threads:[~2024-10-15 11:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-26 22:02 [PATCH v6 08/12] efi_loader: Disable ANSI output for tests Simon Glass
2024-09-26 22:02 ` [PATCH v6 09/12] efi_loader: Add a test app Simon Glass
2024-09-27 13:50   ` Ilias Apalodimas
2024-09-27 16:50     ` Simon Glass
2024-09-30 12:00       ` Heinrich Schuchardt
2024-09-30 14:12         ` Simon Glass
2024-09-26 22:02 ` [PATCH v6 10/12] sandbox: virtio: Disable the sandbox virtio blk device Simon Glass
2024-09-27  0:22   ` Tom Rini
2024-09-26 22:02 ` [PATCH v6 11/12] test: efi: boot: Set up an image suitable for EFI testing Simon Glass
2024-09-26 22:02 ` [PATCH v6 12/12] test: efi: boot: Add a test for the efi bootmeth Simon Glass
2024-10-11 22:32   ` Tom Rini
2024-10-13 19:33     ` Simon Glass
2024-10-14  3:51       ` Tom Rini
2024-10-14  7:00         ` Heinrich Schuchardt
2024-10-14 14:32           ` Tom Rini
2024-10-14 19:13         ` Simon Glass
2024-10-14 21:11           ` Tom Rini
2024-10-15 10:19             ` Mark Kettenis
2024-10-15 11:36               ` Heinrich Schuchardt [this message]
2024-10-15 13:25                 ` Simon Glass
2024-10-15 14:16                   ` Tom Rini

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=23757cf3-c27a-498d-9e66-59261f060102@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=ilias.apalodimas@linaro.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.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.