[Fuego] [PATCH 3/4] LTP: add pre-settings for smack and network related tests
Tim.Bird at sony.com
Tim.Bird at sony.com
Tue Mar 20 04:52:22 UTC 2018
> -----Original Message-----
> From: Liu Wenlong
> About testsuite "smack",
> - refer to [https://github.com/linux-test-project/ltp/blob/master/
> testcases/kernel/security/smack/README]
>
> About networt related tests,
> - refer to [https://github.com/linux-test-project/ltp/blob/master/
> testcases/network/stress/README]
>
> Signed-off-by: Liu Wenlong <liuwl.fnst at cn.fujitsu.com>
> ---
> .../tests/Functional.LTP/scripts/setup_network.sh | 41
> ++++++++++++++++++++++
> engine/tests/Functional.LTP/scripts/setup_smack.sh | 32
> +++++++++++++++++
> engine/tests/Functional.LTP/spec.json | 15 ++++++++
> 3 files changed, 88 insertions(+)
> create mode 100644 engine/tests/Functional.LTP/scripts/setup_network.sh
> create mode 100644 engine/tests/Functional.LTP/scripts/setup_smack.sh
>
> diff --git a/engine/tests/Functional.LTP/scripts/setup_network.sh
> b/engine/tests/Functional.LTP/scripts/setup_network.sh
> new file mode 100644
> index 0000000..b66bb91
> --- /dev/null
> +++ b/engine/tests/Functional.LTP/scripts/setup_network.sh
> @@ -0,0 +1,41 @@
> +#!/bin/sh
> +
> +if [ "$1" == "end" ]; then
> + return 0
> +fi
> +
> +#These tests[1] require two machines. And each machine needs to have 2
> or more
> +#interfaces. These tests assume that they run on the following topology.
> +#
> +# Control Link
> +# +------------------------------------+
> +# | |
> +# +-------+-------+ +-------+-------+
> +# | +---- Test Link 0 ---+ |
> +# | Local Host + : + Remote Host |
> +# | +---- Test Link n ---+ |
> +# +---------------+ +---------------+
> +#
> +# For more details, please refer to [2].
> +
> +# The nestwork stress testcases require the following environment
> variables.
> +# Those variables should be changed before testing to meet your own test
> env.
> +
> +# The host name of the remote host to access it via the control link.
> +export RHOST="192.168.10.51"
> +export RUSER="root"
> +export PASSWD="root"
> +# The blank-separated hardware address list and ethernet interfaces which
> are
> +# connected to a test link at the local/remote host.
> +export LHOST_HWADDRS="00:0e:c6:c5:b2:fe"
> +export RHOST_HWADDRS="00:0e:c6:c5:c0:b4"
> +export LHOST_IFACES="eth1"
> +export RHOST_IFACES="enx000ec6c5c0b4"
I'm not sure I'm following how this works. Does the same test have
to be run simultaneously on 2 boards (DUTs)? Can one be the host
machine? Do the machines need to be of similar performance?
If not, it seems like it would be easier for the user if we always
defaulted to using the Fuego host as one of the endpoints.
We should have enough information about the host (that we can
autodetect) and the board (provided in the board file) to
automatically configure things, in the case where we are using
the host as one of the endpoints.
Does the connection have to be directly wired, or is going
through a bridge or router OK?
> +
> +# [1] tests which require two machines:
> +# net.rpc_tests net_stress.multicast stress.part1 net.nfs
> stress.part3
> +# net.multicast net_stress.route net.tirpc_tests net.rpc
> net.tcp_cmds
> +# Note:
> +# net.rpc_tests (named "rpc_tests" in some LTP version)
> +# net.tirpc_tests (named "tirpc_tests" in some LTP version)
> +# [2] https://github.com/linux-test-
> project/ltp/blob/master/testcases/network/stress/README
> diff --git a/engine/tests/Functional.LTP/scripts/setup_smack.sh
> b/engine/tests/Functional.LTP/scripts/setup_smack.sh
> new file mode 100644
> index 0000000..1d7605e
> --- /dev/null
> +++ b/engine/tests/Functional.LTP/scripts/setup_smack.sh
> @@ -0,0 +1,32 @@
> +#!/bin/sh
> +
> +cat /proc/filesystems | grep smackfs > /dev/null
> +if [ $? -ne 0 ]; then
> + echo "CONFIG_SMACK not configured in your kernel."
Shouldn't this be a NEED_KCONFIG test, in test_pre_check()?
This isn't checking the kernel config, but doing a different dynamic
test. But it still seems like it should be in test_pre_check instead
of here. This implies that there should be a standalone test
"Functional.LTP-smack")
> + exit 1
> +fi
> +
> +if [ "$1" == "start" ]; then
> + mount | grep -v /sys/fs/smackfs | grep /smack > /dev/null
> + if [ $? -eq 0 ]; then
> + return 0
> + fi
> +
> + if [ ! -d /smack ]; then
> + mkdir /smack > /dev/null
> + export NEW_DIR=1
> + fi
> +
> + mount -t smackfs smackfs /smack
> + export NEW_FSTAB=1
> +fi
> +
> +if [ "$1" == "end" ]; then
> + if [ "$NEW_FSTAB" == "1" ]; then
> + umount /smack
> + fi
> +
> + if [ "$NEW_DIR" == "1" ]; then
> + rmdir /smack
> + fi
> +fi
How does the LTP smack test accomplish this setup and teardown
in the non-Fuego case? Is it expected to be performed manually?
I don't understand why the LTP smack test doesn't do this setup
and cleanup itself.
Is this something that should be fixed upstream in LTP?
> diff --git a/engine/tests/Functional.LTP/spec.json
> b/engine/tests/Functional.LTP/spec.json
> index 3b48bdc..b81bb8b 100644
> --- a/engine/tests/Functional.LTP/spec.json
> +++ b/engine/tests/Functional.LTP/spec.json
> @@ -72,6 +72,21 @@
> "tests": "cve",
> "extra_success_links": {"xlsx": "results.xlsx", "skiplist": "skiplist.txt"},
> "extra_fail_links": {"xlsx": "results.xlsx", "skiplist": "skiplist.txt"}
> + },
> + "rpc_tests": {
> + "tests": "net.rpc_tests net.tirpc_tests",
> + "test_operation": "/fuego-
> core/engine/tests/Functional.LTP/scripts/setup_network.sh",
> + "homedir": "/opt/ltp",
> + "extra_success_links": {"xlsx": "results.xlsx", "skiplist": "skiplist.txt"},
> + "extra_fail_links": {"xlsx": "results.xlsx", "skiplist": "skiplist.txt"}
> + },
> + "smack": {
> + "tests": "smack",
> + "skiplist": "smack_file_access smack_set_onlycap",
> + "test_operation": "/fuego-
> core/engine/tests/Functional.LTP/scripts/setup_smack.sh",
> + "homedir": "/opt/ltp",
> + "extra_success_links": {"xlsx": "results.xlsx", "skiplist": "skiplist.txt"},
> + "extra_fail_links": {"xlsx": "results.xlsx", "skiplist": "skiplist.txt"}
I have this nagging feeling that some of these LTP tests are complicated enough
(have their own dependencies, or have their own setup and cleanup, or have
their own output format (and therefore need their own parser)), that it would
be better to create whole new Fuego tests for them, rather than just a
spec on the existing test.
But this approach would come with some additional ramifications for sharing
source code and build directories.
> }
> }
> }
> --
> 2.7.4
This looks a little too complicated, and IMHO it's not using existing Fuego
mechanisms that it could.
-- Tim
More information about the Fuego
mailing list