On Wed, Apr 10, 2024 at 9:36 AM Juraj Linkeš <juraj.lin...@pantheon.tech> wrote: > > On Wed, Apr 10, 2024 at 1:27 PM Luca Vizzarro <luca.vizza...@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> > >
