Difference between revisions of "LTP device discovery protocol"
(→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 == | ||
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 | + | 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 === |
− | |||
− | |||
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 === |
− | |||
− | |||
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 11: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
Contents
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