From: Florian Westphal <fw@strlen.de>
To: Thomas Haller <thaller@redhat.com>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH RFC] tests: add feature probing
Date: Mon, 4 Sep 2023 10:53:01 +0200 [thread overview]
Message-ID: <20230904085301.GC11802@breakpoint.cc> (raw)
In-Reply-To: <c322af5a87a7a4b31d4c4897fe5c3059e9735b4e.camel@redhat.com>
Thomas Haller <thaller@redhat.com> wrote:
> > +check_features()
> > +{
> > + for ffilename in features/*.nft; do
> > + feature=${ffilename#*/}
> > + feature=${feature%*.nft}
> > + eval NFT_HAVE_${feature}=0
> > + $NFT -f "$ffilename" 2>/dev/null
>
> is the "--check" option here missing? At least, the commit message says
Yes, added.
> I think it should run in a separate netns too.
Should not make a difference due to --check, nothing
is altered.
> OK, that's nice, to see in the output.
>
> But why this "nft -f" specific detection? Why not just executable
> scripts?
Because I want it to be simple, it will be enough to drop a ruleset
with the feature into features/ durectory and run-tests.sh would do the
reset.
While its possible to launch nft as a script via
#!/usr/bin/env nft
This would use the system nft, not the newly built one. And fudging
with $PATH seems ugly...
> Also, why should "run-tests.sh" pre-evaluate those NFT_HAVE_* features?
> Just let each tests:
>
> if ! "$BASEDIR/features/chain-binding" ; then
> echo " defaultchain"
> return
> fi
>
> then the checks are more flexible (arbitrary executables).
I could do that, but I don't see the need for arbitrary scripts so far.
> Downside, if the check is time consuming (which it shouldn't),
Agree, it should not.
> then
> tests might call it over and over. Workaround for that: have "run-
> tests.sh" prepare a temporary directory and export it as
> $NFT_TEST_TMPDIR". Then "features/chain-binding" can cache the result
> there. "run-tests.sh" would delete the directory afterwards.
>
> If you want to print those features, you can still let run-tests.sh
> iterate over "$BASEDIR"/features/* and print the result.
Yes, thats a working alternative but I don't see the need for this.
> > diff --git a/tests/shell/testcases/transactions/30s-stress
> > b/tests/shell/testcases/transactions/30s-stress
> > index 4d3317e22b0c..924e7e28f97e 100755
> > --- a/tests/shell/testcases/transactions/30s-stress
> > +++ b/tests/shell/testcases/transactions/30s-stress
> > @@ -16,6 +16,18 @@ if [ x = x"$NFT" ] ; then
> > NFT=nft
> > fi
> >
> > +if [ -z $NFT_HAVE_chain_binding ];then
> > + NFT_HAVE_chain_binding=0
> > + mydir=$(dirname $0)
>
> I think run-tests.sh should export the base directory, like "$BASEDIR",
> or "$NFT_TEST_BASEDIR". Tests should use it (and rely to have it).
Can do that.
> ah, you'd have each tests re-implement the check? So that they can run
> without the "run-tests.sh" wrapper?
No, just 30s-stress. This test is special because its random by nature
and it makes sense to run it for multiple hours once in a while.
> The point here is, that if the "run-tests.sh" wrapper can provide
> something useful, then tests should be able to rely on it (and don't
> implement a fallback path).
Yes, no other script will do this.
I'll send an updated batch soon to see how this looks like with more
feature tests in place.
next prev parent reply other threads:[~2023-09-04 8:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 13:51 [PATCH RFC] tests: add feature probing Florian Westphal
2023-09-01 11:58 ` Florian Westphal
2023-09-01 15:37 ` Thomas Haller
2023-09-04 8:53 ` Florian Westphal [this message]
2023-09-06 5:44 ` Thomas Haller
2023-09-06 10:04 ` Florian Westphal
2023-09-06 11:03 ` Pablo Neira Ayuso
2023-09-06 11:33 ` Thomas Haller
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=20230904085301.GC11802@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=thaller@redhat.com \
/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).