netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).