On 25 Mar 2019, at 10:55, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Mon, 25 Mar 2019 at 10:47, Tim Jaacks <tim.jaacks@garz-fricke.com mailto: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...
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 low on priority list: https://git.lavasoftware.org/lava/lava/issues/228 https://git.lavasoftware.org/lava/lava/issues/228
So 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 current implementation. Please bear in mind that new implementation should keep old script names at least for some time so tests using them can be 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
I'm not entirely convinced you need the device dict access feature to make it work for you. I would only pass the relevant device to the container and make a symlink there. Also relying on the enumeration (ttyUSB0-3) isn't usually the best idea as these might change when restarting your host or plugging/unplugging devices. Using /dev/serial/by-id is usually a better strategy. This however is orthogonal to the question in the subject.
milosz
Hope to get some useful replies here. Thanks in advance.
Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks@garz-fricke.com www.garz-fricke.com WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Lava-devel mailing list Lava-devel@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-devel
Lava-devel mailing list Lava-devel@lists.lavasoftware.org mailto:Lava-devel@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-devel https://lists.lavasoftware.org/mailman/listinfo/lava-devel