Re: [PATCH 5/6] dts: add statefulness to InteractiveShell

[Jeremy Spewock <jspewock@iol.unh.edu>]

On Wed, Apr 10, 2024 at 9:36 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:
>
> On Wed, Apr 10, 2024 at 1:27 PM Luca Vizzarro <Luca.Vizzarro@arm.com> wrote:
> >
> > On 10/04/2024 07:53, Juraj Linkeš wrote:
> > > I have a general question. What are these changes for? Do you
> > > anticipate us needing this in the future? Wouldn't it be better to add
> > > it only when we need it?
> >
> > It's been sometime since we raised this task internally. This patch and
> > the next one arise from some survey done on old DTS test cases.
> > Unfortunately, I can't pinpoint.
> >
> > Specifically for this patch though, the timeout bit is useful in
> > conjunction with the related change in the next. Instead of giving an
> > optional timeout argument to all the commands where we may want to
> > change it, aren't we better off with providing a facility to temporarily
> > change this for the current scope?
> >
>
> This is a good question. If the scope is just one command, then no. If
> it's more than one, then maybe yes. I don't know which is better.
>
> We should also consider that this would introduce a difference in API
> between the interactive and non-interactive sessions. Do we want to do
> this there as well?

I believe there already is a difference in this case since the
interactive shell doesn't support modification of timeout on a
per-command basis. This is mainly because the way interactive shells
handle timeouts is on a lower level than sending a command using
fabric. Currently the interactive shells are modifying the timeout on
the channel of the connection, whereas fabric supports a keyword
argument that can modify timeouts on a per-command basis.

Of course we could also change the interactive shell send_command to
modify the timeout of the shell, but something else to note here is
that changing the timeout of the channel of the connection is slightly
different than giving a timeout for a command. This is because when
you change the timeout of the channel you're setting the timeout for
read/write operations on that channel. So, if you send a command and
give a timeout of 5 seconds for example, as long as you are receiving
output from the shell at least every 5 seconds, the command actually
wouldn't ever timeout. If we want to make the interactive shell
support passing a timeout per command, I would recommend we do it in a
different way that is more representative of your *command* having a
timeout instead of the shell's channel having a timeout.

Waiting for the status of a link to be "up" in testpmd was an
exception where I did allow you to give a specific timeout for the
command and this is exactly for the reason above. I wanted to make
sure that the user was able to specify how long they wanted to wait
for this status to be what they expect as opposed to how long to wait
for getting output from the channel. This is not supported in any
other method of the interactive shell.

>
> Also, maybe set_timeout should be a property or we could just make
> _timeout public.
> And is_privileged should just be privileged, as it's a property (which
> shouldn't contain a verb; if it was a method it would be a good name).
<snip>
> >