[PATCH v5 10/14] efi_loader: Disable ANSI output for tests

[Simon Glass]

Hi Tom,

On Tue, 17 Sept 2024 at 19:00, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Sep 17, 2024 at 05:54:36AM +0200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 16 Sept 2024 at 18:33, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Mon, Sep 16, 2024 at 05:42:12PM +0200, Simon Glass wrote:
> > > > Hi Heinrich,
> > > >
> > > > On Thu, 12 Sept 2024 at 08:58, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > > >
> > > > > On 02.09.24 03:18, Simon Glass wrote:
> > > > > > We don't want ANSI characters written in tests since it is a pain to
> > > > > > check the output with ut_assert_nextline() et al.
> > > > > >
> > > > > > Provide a way to tests to request that ANSI characters not be sent.
> > > > > >
> > > > > > Add a proper function comment while we are here, to encourage others.
> > > > > >
> > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > >
> > > > >
> > > > > This patch was already NAKed in the last version.
> > > > >
> > > > > Please, adjust the test framework if you need filtering.
> > > >
> > > > In what way should it be adjusted? I hope you are not suggesting that
> > > > sandbox should try to filter out ANSI characters in its assertions?
> > >
> > > Well, perhaps the pytest framework should be filtering it out? And
> > > again and to be clear, I can't reliably run these tests on _hardware_
> > > because of the ANSI characters tripping things up, this is not a
> > > "sandbox" problem.
> >
> > Honestly, this approach (creating a problem and then dealing with it
> > downstream) is just not the way things should be.
>
> I don't follow, sorry.

I'm not sure I do either. I thought you were saying that the ANSI
characters should be generated and then some other feature should
filter them out, so that tests can pass.

My point then was that it doesn't make any sense to generate something
which causes a problem...just fix the issue at its source and don't
generate the characters.

>
> > As an alternative, I can send a patch to remove the code which blindly
> > sends commands to a terminal which may or may not be there. That would
> > be more correct than what we have today. We can then discuss how to
> > add ANSI back, with due thought to its downstream impact.
>
> I admit I only get as far as "Oh, selftest failed and look at all that
> escape sequence and such in the log" which I take as pytest choked on
> the output. Maybe we have different issues?
>
> > It's not great that  this discussion is still happening on a v5 patch.
> > There has been plenty of opportunity to provide an alternative option.
> > I doubt any exists.
>
> Well, it's _also_ true that people have been providing feedback earlier
> in the series and requesting changes and I don't know if it's missed
> because you were dropped from the list again or buried in your inbox or
> what. But you repost and don't drop / change patches that there's not
> yet agreement on.

I do seem to miss emails every now and then, as I regularly get
dropped from the list and have to re-subscribe.

But in this case the suggestion to add filtering does not make any
sense, so I have rejected it. The solution I have here is the best
approach I can think of.

Regards,
Simon