Since all other apps have been moved to the "app" folder, the autotest app
remains alone in the test folder. Rather than having an entire top-level
folder for this, we can move it back to where it all started in early
versions of DPDK - the "app/" folder.
This move has a couple of advantages:
* This reduces clutter at the top level of the project, due to one less
folder.
* It eliminates the separate build task necessary for building the
autotests using make "make test-build" which means that developers are
less likely to miss something in their own compilation tests
* It re-aligns the final location of the test binary in the app folder when
building with make with it's location in the source tree.
For meson builds, the autotest app is different from the other apps in that
it needs a series of different test cases defined for it for use by "meson
test". Therefore, it does not get built as part of the main loop in the
app folder, but gets built separately at the end.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
This is to logically group unit tests into their own folder,
separating them from "app" folder.
Hopefully this will make the unit test in DPDK more visible.
Following binaries moved to "test" folder:
cmdline-test
test-acl
test-pipeline
test <-- various DPDK unit tests
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The tests are registered with their command name by adding a structure
to a list. The structure of each test was declared in each test file
and passed to the register macro.
This rework generate the structure inside the register macro.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Jan Viktorin <viktorin@rehivetech.com>
The commit 66819e6 has introduced a dependency on libarchive to be able
to use some tar resources in the unit tests.
It is now an optional dependency because some systems do not have it
installed.
If CONFIG_RTE_APP_TEST_RESOURCE_TAR is disabled, the PCI test will not
be run. When a "configure" script will be integrated, the libarchive
availability could be checked to automatically enable the option.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Jan Viktorin <viktorin@rehivetech.com>
When a more complex resource (a file hierarchy) is needed, packing
every single file as a single resource would be very ineffective. For
that purpose, it is possible to pack the files into a tar archive,
extract it before test from the resource and finally clean up all the
created files.
This patch introduces functions resource_untar and resource_rm_by_tar
to perform those tasks. An example of using those functions is included
as a test.
A new dependency is required to build the app/test: libarchive.
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
A resource can be written into the target filesystem by calling
resource_fwrite or resource_fwrite_file. Such file can be created
before a test is started and removed after the test finishes.
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
To include resources from other source that the C source code we
can take advantage of the objcopy behaviour, i.e. packing of an
arbitrary file as an object file that is linked to the target program.
A linked object file is always accessible as a pair
extern const char beg_<name>;
extern const char end_<name>;
(extern const char siz_<name>;)
A unit test that packs the resource.c source file is included.
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Certain internal mechanisms of DPDK access different file system
structures (e.g. /sys/bus/pci/devices). It is difficult to test
those cases automatically by a unit test when such path is not
hard-coded and there is no simple way how to distribute fake ones
with the current testing environment.
This patch adds a possibility to declare a resource embedded in
the test binary itself. The structure resource cover the generic
situation - it provides a name for lookup and pointers to the
embedded data blob. A resource is registered in a constructor by
the macro REGISTER_RESOURCE.
Some initial tests of simple resources is included and added into
the group_1.
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
