[PATCH v5 17/20] test: Try to shut down the lab console gracefully

[Simon Glass]

Hi Tom,

On Tue, 3 Sept 2024 at 12:48, Tom Rini <trini at konsulko.com> wrote:
>
> On Sun, Sep 01, 2024 at 02:09:58PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 30 Aug 2024 at 08:26, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Aug 29, 2024 at 07:04:36PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 29 Aug 2024 at 10:59, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Thu, Aug 29, 2024 at 09:01:17AM -0600, Simon Glass wrote:
> > > > > > Hi Neil,
> > > > > >
> > > > > > On Thu, 29 Aug 2024 at 08:26, <neil.armstrong at linaro.org> wrote:
> > > > > > >
> > > > > > > On 29/08/2024 00:08, Simon Glass wrote:
> > > > > > > > Send the Labgrid quit characters to ask it to exit gracefully. This
> > > > > > > > typically allows it to power off the board being used.
> > > > > > >
> > > > > > > Sending those characters every time could collide with other CI systems,
> > > > > > > I don't think it's a good idea.
> > > > > >
> > > > > > What systems are you thinking about and what sort of collision would occur?
> > > > > >
> > > > > > What do you suggest instead?
> > > > >
> > > > > Why do we need this at all? Did I miss where we send picocom the
> > > > > disconnect nicely key-combination?
> > > >
> > > > When labgrid gets a signal, it exits. It doesn't continue its
> > > > co-routines and execute the end strategy to power things off, etc. I
> > > > suspect it could be made to do that, but I already have 62 Labgrid
> > > > patches, so I thought this would be expedient...
> > > >
> > > > I can make this conditional on the new USE_LABGRID variable.
> > >
> > > It sounds to me like we need to make generic improvements to our hooks
> > > then, if there's not a "now call poweroff" hook.
> >
> > The thing is, Labgrid has its own internal console, which allows me to
> > see all the output from reset. If I use picocom or some other program
> > then some of the output is gone by the time I connect, particularly
> > when using USB download. Because of that, just killing Labgrid, which
> > is what pytest does, is a pretty heavy hammer and leaves things in an
> > unknown state. So I added this method to give it a software signal.
>
> OK, but we shouldn't care? You can have the console available to pytest
> and a terminal at the same time, with labgrid. If you need to see before
> pytest grabs it, have the terminal be the first console, not pytest?

I'm a bit lost at this point...'labgrid-client console' creates a
console connection and it keeps running until killed, with that
console connection connected between its stdin/stdout. Then pytest
uses that.

There is only one console.

I care because missing output makes it impossible to see what went
wrong, if something went wrong.

> This gets back again I think to your specific way of making use of
> labgrid contrasting with just generally supporting labgrid with however
> another physical lab has set it up. Does killing one connection really
> reset all of them? Or was it just a conflict with your
> auto-acquire/release?

Are you talking about the Labgrid exporter, perhaps? This patch is for
the client and we have one client process running for each board we
connect to. You can see that in the Labgrid version of the
u-boot-test-console script which basically runs labgrid-client and
let's it do the talking.

Regards,
Simon