[Fuego] [PATCH 3/4] LTP: add pre-settings for smack and network related tests
Liu, Wenlong
liuwl.fnst at cn.fujitsu.com
Tue Mar 20 06:01:07 UTC 2018
> -----Original Message-----
> From: Tim.Bird at sony.com [mailto:Tim.Bird at sony.com]
> Sent: Tuesday, March 20, 2018 12:52 PM
> To: Liu, Wenlong/刘 文龙 <liuwl.fnst at cn.fujitsu.com>;
> fuego at lists.linuxfoundation.org
> Subject: RE: [Fuego] [PATCH 3/4] LTP: add pre-settings for smack and network
> related tests
>
> > -----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?
The host machine can be used as the HOST machine and the Fuego host can be one of the endpoints.
In my lab, the connection was wired, but I think bridge and router are also 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?
It's a good opinion, thanks.
Those smack related tests are old enough. Maybe I should ask the LTP member about this first.
> > 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.
OK, I was also thinking to do those settings in new Fuego tests like AGL-JTA do.
Why do it this way is because I think it's easy to do all LTP tests within one test.(sorry, in my own opinion:-).)
Sorry, I didn't realize that it will be more complicated and make new users more confusing.
Yes, tests like smack and network, we can create some new tests in Fuego that same with
those tests in AGL-JTA, e.g. Functional.LTP.Net_Stress and Functional.LTP.Open_Posix.
I will still work on this once I have some time, if there is no one fix this earlier;-).
Thanks for your review and opinions.
> -- Tim
>
More information about the Fuego
mailing list