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

[Simon Glass]

Hi Tom,

On Fri, 6 Sept 2024 at 12:43, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Sep 05, 2024 at 06:50:20PM -0600, Simon Glass wrote:
> > 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.
>
> There's not one console, is what I'm saying. You can connect to the
> console via a terminal while pytest is running from another terminal. So
> if you have a problem and it's in that window where we're just starting
> up, grab the console for you first and then let pytest go second.

This patch is actually about gracefully closing down labgrid-client.

When pytest is running tests on a board, I don't need/want to connect
to it separately.

Note that with labgrid I added an internal terminal, to avoid picocom
(or microcom) losing the initial output. I can't really say it any
other way. It definitely happens and it is definitely a problem,
promise!

This patch is about letting labgrid shut down nicely, rather than
leave things in a strange state, requiring a separate call to power
things down, for example.

>
> > > 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.
>
> It's about the assumptions that are true for your lab (and possibly
> others) that aren't true for my lab (and possibly others).

OK. I'm very happy with my lab at the moment. It permits pytest,
interactive use and gitlab. But, yes, there are many ways to do all this...

Regards,
Simon