Difference between revisions of "LTP device discovery protocol"

From eLinux.org
Jump to: navigation, search
(test meta-data)
(convert md headings to mediawiki headings)
Line 3: Line 3:
 
From https://patchwork.ozlabs.org/project/ltp/patch/20200623112827.10744-2-chrubis@suse.cz/#2465790
 
From https://patchwork.ozlabs.org/project/ltp/patch/20200623112827.10744-2-chrubis@suse.cz/#2465790
  
Device discovery
+
= Device discovery =
----------------
 
 
 
The problem
 
-----------
 
  
 +
== The problem ==
 
Each lab has a different hardware capabilities and configuration. A test
 
Each lab has a different hardware capabilities and configuration. A test
 
that heavily depends on a hardware needs to get this information in
 
that heavily depends on a hardware needs to get this information in
 
order to be able to run correctly.
 
order to be able to run correctly.
  
The solution
+
== The solution ==
------------
 
 
 
 
The test declares which devices it needs for a testing. In the uart test
 
The test declares which devices it needs for a testing. In the uart test
 
these are UART_RX and UART_TX which are two UART endpoints which are
 
these are UART_RX and UART_TX which are two UART endpoints which are
Line 21: Line 16:
  
 
This information is then passed as a parameter to a device-discovery.sh
 
This information is then passed as a parameter to a device-discovery.sh
script that prints, possibly several lines, of device listrs, which is
+
script that prints, possibly several lines, of device lists, which is
 
then parsed by the test library and the test is executed accordingly.
 
then parsed by the test library and the test is executed accordingly.
  
Line 29: Line 24:
 
test around the lists we got.
 
test around the lists we got.
  
Why this solution?
+
== Why this solution? ==
------------------
 
 
 
 
The device discovery is lab specific and does not belong to the test
 
The device discovery is lab specific and does not belong to the test
 
itself. This is an attempt to abstract the interface between the test
 
itself. This is an attempt to abstract the interface between the test
Line 37: Line 30:
 
LTP.
 
LTP.
  
Missing pieces
+
== Missing pieces ==
--------------
 
 
 
 
There are stil a few missing pieces, but these are probably easy to fix
 
There are stil a few missing pieces, but these are probably easy to fix
 
as well.
 
as well.
  
Device reconfiguration
+
=== Device reconfiguration ===
11:07, 14 September 2020 (PDT)11:07, 14 September 2020 (PDT)11:07, 14 September 2020 (PDT)11:07, 14 September 2020 (PDT)~~
 
 
 
 
I suppose that we may need to run a command so that the devices are
 
I suppose that we may need to run a command so that the devices are
 
reconfigured as we need them. I.e. the device-discovery.sh will have to
 
reconfigured as we need them. I.e. the device-discovery.sh will have to
Line 51: Line 40:
 
physical environment e.g. relays in case of the UART.
 
physical environment e.g. relays in case of the UART.
  
Device parameters
+
=== Device parameters ===
11:07, 14 September 2020 (PDT)11:07, 14 September 2020 (PDT)11:07, 14 September 2020 (PDT)~~
 
 
 
 
We may as well need some extra info about the devices, e.g. is hardware
 
We may as well need some extra info about the devices, e.g. is hardware
 
flow connected in case of UART. So the device-discover.sh will add one
 
flow connected in case of UART. So the device-discover.sh will add one
 
more environment variable e.g. UART_PARS="hwflow" that could be parsed
 
more environment variable e.g. UART_PARS="hwflow" that could be parsed
 
in the test as well.
 
in the test as well.
 
  
 
-----
 
-----

Revision as of 10:13, 14 September 2020

Here is some information from Cyril Hrubis on the rationale for this system:

From https://patchwork.ozlabs.org/project/ltp/patch/20200623112827.10744-2-chrubis@suse.cz/#2465790

Device discovery

The problem

Each lab has a different hardware capabilities and configuration. A test that heavily depends on a hardware needs to get this information in order to be able to run correctly.

The solution

The test declares which devices it needs for a testing. In the uart test these are UART_RX and UART_TX which are two UART endpoints which are connected together.

This information is then passed as a parameter to a device-discovery.sh script that prints, possibly several lines, of device lists, which is then parsed by the test library and the test is executed accordingly.

The data are passed to the test as a environment variables, if these are set prior to the test start, we do not even attempt to do a device discovery. If these are unset, we run the device discovery and loop the test around the lists we got.

Why this solution?

The device discovery is lab specific and does not belong to the test itself. This is an attempt to abstract the interface between the test and the hardware so that we can finally add device drivers tests into LTP.

Missing pieces

There are stil a few missing pieces, but these are probably easy to fix as well.

Device reconfiguration

I suppose that we may need to run a command so that the devices are reconfigured as we need them. I.e. the device-discovery.sh will have to output a command that needs to be executed in order to prepare the physical environment e.g. relays in case of the UART.

Device parameters

We may as well need some extra info about the devices, e.g. is hardware flow connected in case of UART. So the device-discover.sh will add one more environment variable e.g. UART_PARS="hwflow" that could be parsed in the test as well.


test meta-data

A LTP test can express it's requirement for devices in it's tst_test structure, as a list of strings indicating the environment variable names for items that it needs in order to execute:

Here is an example for a uart (serial port) test:

static struct tst_test test = {
 .setup = setup,
 .test_all = run,
 .options = (struct tst_option[]) {
   {"b:", &baud_rate, "-b       Baud rate (9600, ...)"},
   {"w",  &hwflow   , "-w       Enable hwflow (RTS/CTS)"},
   {"f:",  &fname,    "-f       Binary file for transfers"},
   {"s:",  &buf_size, "-s       Binary buffer size"},
   {}
 },
 .needs_devices = (const char *const[]) {"UART_RX", "UART_TX", NULL},
 .forks_child = 1,
};

This shows that this test requires UART_RX and UART_TX to be defined. These environment variables are expected to be filled with strings indicating the Linux device which represents the serial ports on the receiving and transmitting side of the test, respectively. For example, you might have: UART_RX=/dev/tty