Option for postponed execution of "on_activate()" code for ShellDriver and SSHDriver

[nmhaker]

Dear, I will try to explain the issue we are having in hope that there is already some solution that you can give us to the problem we have, that we are not aware of, so that we don't need to change labgrid native code.

Our understanding is as follows:

ShellDriver and SSHDriver on_activate() method is being executed automatically via labgrid lifecycle once Environment.yaml is parsed in which these drivers are used.
However code inside on_activate() is unconditionally trying to, in case of ShellDriver get to the prompt, while in case of SSHDriver, establish functional ssh connection.
Now this is a problem for our case where we use Labgrid, extended on our side, to do low level flashing of devices.
As when trying to flash device you can have device which doesn't have working image:

• Device has no image at all until flashed
  • not possible to get shell prompt to this device -> ShellDriver initialization fails
  • not possible to get ssh connection to this device -> SSHDriver initialization fails
• Flashing failed so device left in bricked image mode
  • same...
  • same...
• Some other reason that left device into non connectable state in some mode, where pure serial (console) connection only maybe can be used.
  • same...
  • same...

However since this happens during initialization of labgrid and parsing of Environment.yaml we can't react and prevent this so labgrid times out, crashes.

In our case it would be ok if labgrid initialized successfully, without trying to establish shell and ssh connection, but initializing drivers nevertheless.
And later when we use them we have opportunity to activate them in defined way.

Our solution was to change labgrid drivers and add parameter to ShellDriver and SSHDriver and use it in in a fixed way set in our environment.yaml so that we skip this unnecessary initial connections. However that has implication that, as long as you use that same environment.yaml, shell and ssh commands will not work from labgrid-client as initial stuff is skipped that should happen in this case, but not for our command. So basically we plan to mitigate this by using separate environment.yaml files...

Is there any better solution than this ?
Could it be that nobody up until know had this use case, or lets say, expected to use labgrid on device that doesn't have "functionally running linux" ?

I imagine that there are probably other drivers having the same issue/use-case that I didn't mention here.