On Mon, 25 Mar 2019 at 10:47, Tim Jaacks <tim.jaacks@garz-fricke.com> wrote:
Dear LAVA team,
in my LAVA setup I need to connect my DUTs to certain interfaces on the worker. The information which of my DUTs is connected to which interface has to be available in my test shell somehow. The documentation gives the impression that LAVA is capable of this:
https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html?highlight=energy#arbitrary-external-devices-needing-lxc-support
It says: "Other static devices which are accessible over the network can be made available to a test shell in the LXC through lava test shell helpers".
Browsing through the code shows that this is implemented only for one single use-case, though, that is energy probes (via helpers "lava-probe-ip" and "lava-probe-channel"). There does not seem to be any generic mechanism to make static device info available in the test shell. The documentation is quite misleading here in my opinion, since it does not reflect the actual implementation.
I have asked about this on the lava-users mailing list, and Neil confirmed my investigation:
https://lists.lavasoftware.org/pipermail/lava-users/2019-March/001741.html
He answered my question, whether there is a generic mechanism to supply static_info from the device dictionary in the LAVA test shell, with "Not currently".
Is such a feature planned? If not, would you accept code contributions which add such a feature?
I asked about this feature for some time but it's usually pretty lowon priority list:https://git.lavasoftware.org/lava/lava/issues/228So if you come up with some solution I'd be very happy about that :)I actually do not see why the two helpers for the energy probes have been hard-coded in the first place. Why hasn't this been implemented in a generic way from the beginning?
In my idea, there would be only one single function "lava-static-info" which outputs the complete static info array in some form. The caller can then extract the info he needs from there. Is there any reason against such an extension?
I don't know any except for lack of engineering time to fix currentimplementation. Please bear in mind that new implementation shouldkeep old script names at least for some time so tests using them canbe updated without time pressure.
Alternatively, are there any other suggestions on how to implement my use case? To make it clear once again: I have four USB-RS232 converters, available on the worker as /dev/ttyUSB0 to /dev/tty/USB3. I have four DUTs, each of which is connected to one of the converters. The test shell has to know which of the TTY devices to use for the test, depending on the actual DUT chosen by the LAVA scheduler.
You can access devices from the lxc if it’s just serial by configuring ser2net with the appropriate /dev/serial/by-id path, however this doesn’t solve the problem of passing in the knowledge of which particular port to use based on the DUT.
I think this might involve a slight addition to the base device-type, but I don’t think it should involve a codebase change.
Remi?
Dave