[PATCH v6 08/12] efi_loader: Disable ANSI output for tests

Tom Rini trini at konsulko.com
Sat Oct 12 02:36:11 CEST 2024


On Sat, Oct 12, 2024 at 01:45:10AM +0200, Heinrich Schuchardt wrote:
> 
> 
> Am 12. Oktober 2024 00:54:38 MESZ schrieb Tom Rini <trini at konsulko.com>:
> >On Fri, Oct 11, 2024 at 04:18:07PM -0600, Simon Glass wrote:
> >
> >[snip]
> >> No other subsystem generates ANSI characters when U-Boot starts. Why
> >> are we creating this problem in the EFI implementation?
> >> 
> >> So please, I very-much want to have a way to stop this output from
> >> being generated, not to filter it afterwards. As above, we should
> >> design U-Boot for easy testing, not treat it as a black box. Please do
> >> seriously consider this as I believe this is an important testing
> >> principle being violated here.
> >
> >This is, I think, a good point. Outside of user-facing interactive
> >code, we don't use ANSI sequences for printing information in
> >U-Boot anywhere else. Why are we doing it in the EFI_LOADER code outside
> >of personal preference? And, can we just not instead? It does confuse
> >matters (as my example showed) when problems do arise.
> 
> Tests should be executable on any U-Boot instance. I see no virtue in a sandbox only hack.

Right, and I want to know what the particular problematic escape
sequences are because right now it does, on hardware, when things fail,
put a bunch of un-rendered escape sequences on the console. That's why I
was "What's going on?" and not seeing that it was the banner count
issue.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241011/1dec5ff1/attachment.sig>


More information about the U-Boot mailing list