From: Jakub Kicinski <kuba@kernel.org>
To: Michal Michalik <michal.michalik@intel.com>
Cc: netdev@vger.kernel.org, vadim.fedorenko@linux.dev,
arkadiusz.kubalewski@intel.com, jonathan.lemon@gmail.com,
pabeni@redhat.com, poros@redhat.com, milena.olech@intel.com,
mschmidt@redhat.com, linux-clk@vger.kernel.org,
bvanassche@acm.org, davem@davemloft.net, edumazet@google.com
Subject: Re: [PATCH RFC net-next v4 2/2] selftests/dpll: add DPLL system integration selftests
Date: Wed, 29 Nov 2023 09:39:51 -0800 [thread overview]
Message-ID: <20231129093951.3be1bd8b@kernel.org> (raw)
In-Reply-To: <20231123105243.7992-3-michal.michalik@intel.com>
On Thu, 23 Nov 2023 05:52:43 -0500 Michal Michalik wrote:
> The tests are written in Python3 (3.7+) and pytest testing framework.
> Framework is basing on the ynl library available in the kernel tree
> at: tools/net/ynl
LGTM!
Somewhat tangential question, a nit, and a comment..
> The DPLL system integration tests are meant to be part of selftests, so
> they can be build and run using command:
> make -C tools/testing/selftests
>
> Alternatively, they can be run using single command [1]:
> make kselftest
>
> If we want to run only DPLL tests, we should set the TARGETS variable:
> make -C tools/testing/selftests TARGETS=drivers/net/netdevsim/dpll
>
> They can also be run standalone using starter script:
> ./run_dpll_tests.sh
>
> There is a possibliy to set optional PYTEST_PARAMS environment variable
> to set the pytest options, like tests filtering ("-k <filter>") or
> verbose output ("-v").
>
> [1] https://www.kernel.org/doc/html/v5.0/dev-tools/kselftest.html
nit: s/v5.0/v6.6/ ? Or /v5.0/latest/
Did you try to run it in vmtest or virtme-ng?
https://www.youtube.com/watch?v=NT-325hgXjY
https://lpc.events/event/17/contributions/1506/attachments/1143/2441/virtme-ng.pdf
I'm thinking of using those for continuous testing, curious all
the Python setup works okay with them.
> +@pytest.fixture(scope="class", params=((0,), (1, 0), (0, 1)))
We have both uses of pytest and unittest in the kernel:
$ git grep --files-with-matches '^import .*unittest'
scripts/rust_is_available_test.py
tools/crypto/ccp/test_dbc.py
tools/perf/pmu-events/metric_test.py
tools/testing/kunit/kunit_tool_test.py
tools/testing/selftests/bpf/test_bpftool.py
tools/testing/selftests/tpm2/tpm2.py
tools/testing/selftests/tpm2/tpm2_tests.py
$ git grep --files-with-matches '^import .*pytest'
scripts/kconfig/tests/conftest.py
tools/testing/selftests/drivers/sdsi/sdsi.sh
tools/testing/selftests/drivers/sdsi/sdsi_test.py
tools/testing/selftests/hid/tests/base.py
tools/testing/selftests/hid/tests/conftest.py
tools/testing/selftests/hid/tests/test_gamepad.py
tools/testing/selftests/hid/tests/test_mouse.py
tools/testing/selftests/hid/tests/test_multitouch.py
tools/testing/selftests/hid/tests/test_sony.py
tools/testing/selftests/hid/tests/test_tablet.py
tools/testing/selftests/hid/tests/test_usb_crash.py
tools/testing/selftests/hid/tests/test_wacom_generic.py
unittest seems a bit more popular but pytest does seem like
a better fit indeed.
Did you see what the sdsi test does? It seems to assume everything
is installed locally, without the venv. I wonder if that may be simpler
to get going with vmtest?
next prev parent reply other threads:[~2023-11-29 17:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 10:52 [PATCH RFC net-next v4 0/2] selftests/dpll: DPLL subsystem integration tests Michal Michalik
2023-11-23 10:52 ` [PATCH RFC net-next v4 1/2] netdevsim: implement DPLL for subsystem selftests Michal Michalik
2023-11-23 12:24 ` Jiri Pirko
2023-11-30 16:55 ` Michalik, Michal
2023-12-01 7:49 ` Jiri Pirko
2023-11-23 14:41 ` Simon Horman
2023-11-30 17:22 ` Michalik, Michal
2023-11-23 10:52 ` [PATCH RFC net-next v4 2/2] selftests/dpll: add DPLL system integration selftests Michal Michalik
2023-11-29 17:39 ` Jakub Kicinski [this message]
2023-11-30 17:46 ` Michalik, Michal
2023-12-01 6:51 ` Jakub Kicinski
2023-12-01 18:33 ` Michalik, Michal
2023-12-01 19:52 ` Jakub Kicinski
2023-12-04 12:44 ` Michalik, Michal
2023-12-05 3:02 ` Jakub Kicinski
2023-12-01 20:03 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231129093951.3be1bd8b@kernel.org \
--to=kuba@kernel.org \
--cc=arkadiusz.kubalewski@intel.com \
--cc=bvanassche@acm.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jonathan.lemon@gmail.com \
--cc=linux-clk@vger.kernel.org \
--cc=michal.michalik@intel.com \
--cc=milena.olech@intel.com \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=poros@redhat.com \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).