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 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?
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.
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
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...
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
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.
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
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
On 25 Mar 2019, at 10:55, Milosz Wasilewski <milosz.wasilewski at linaro.org> wrote:
On Mon, 25 Mar 2019 at 10:47, Tim Jaacks <tim.jaacks at garz-fricke.com <mailto:tim.jaacks at 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 :)
Milosz, thanks for pointing me to that issue. I will join the discussion there.
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.
Thanks for your reply, Dave. I already have the remote devices in my LXC by adding them to static info. However, as you say, the test still does not know which of them to use for which 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.
How would you do that?
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.comhttp://www.garz-fricke.com/ WE MAKE IT YOURS! [cid:image001.jpg@01D4E308.D8842750] Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hello,
Le lun. 25 mars 2019 à 12:17, Dave Pigott dave.pigott@linaro.org a écrit :
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 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
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.
This go down to https://git.lavasoftware.org/lava/lava/issues/228 which is how to grab device-dict information about the current DUT when running a test shell. If you come up with a clean solution, I will be happy to review it. But as Milosz said, this is really low on my priority list.
Rgds
Von: Lava-devel lava-devel-bounces@lists.lavasoftware.org Im Auftrag von Remi Duraffort Gesendet: Dienstag, 9. April 2019 11:40 An: Dave Pigott dave.pigott@linaro.org Cc: lava-devel@lists.lavasoftware.org Betreff: Re: [Lava-devel] Making device static info available in the test shell
Hello,
Le lun. 25 mars 2019 à 12:17, Dave Pigott dave.pigott@linaro.org a écrit :
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 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
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.
This go down to https://git.lavasoftware.org/lava/lava/issues/228 which is how to grab device-dict information about the current DUT when running a test shell. If you come up with a clean solution, I will be happy to review it. But as Milosz said, this is really low on my priority list.
Hi Rémi, thanks for the reply. I already joined the LAVA gitlab and made some suggestions for possible solutions in the mentioned ticket. Could you review these and comment on them? I am new to the code, so I don’t want so start hacking without a good approach in mind.
Rgds
-- Rémi Duraffort
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.comhttp://www.garz-fricke.com/ WE MAKE IT YOURS! [cid:image001.jpg@01D4EEC9.A16E13D0] Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
lava-devel@lists.lavasoftware.org
-
Dave Pigott -
Milosz Wasilewski -
Remi Duraffort -
Tim Jaacks