From: Petr Machata <petrm@nvidia•com>
To: Petr Machata <me@pmachata•org>
Cc: Benjamin Poirier <benjamin.poirier@gmail•com>,
Petr Machata <petrm@nvidia•com>,
Hangbin Liu <liuhangbin@gmail•com>,
"David S. Miller" <davem@davemloft•net>,
Eric Dumazet <edumazet@google•com>,
Jakub Kicinski <kuba@kernel•org>, Paolo Abeni <pabeni@redhat•com>,
<netdev@vger•kernel.org>, Shuah Khan <shuah@kernel•org>,
<mlxsw@nvidia•com>, Jonathan Toppins <jtoppins@redhat•com>
Subject: Re: [PATCH net-next] selftests: forwarding: Import top-level lib.sh through $lib_dir
Date: Wed, 13 Dec 2023 11:31:50 +0100 [thread overview]
Message-ID: <87y1dyl635.fsf@nvidia.com> (raw)
In-Reply-To: <877climn45.fsf@nvidia.com>
Petr Machata <me@pmachata•org> writes:
> Benjamin Poirier <benjamin.poirier@gmail•com> writes:
>
>> On 2023-12-12 18:22 +0100, Petr Machata wrote:
>>>
>>> Hangbin Liu <liuhangbin@gmail•com> writes:
>>>
>>> > On Mon, Dec 11, 2023 at 01:01:06PM +0100, Petr Machata wrote:
>>> >
>>> >> @@ -38,7 +38,7 @@ if [[ -f $relative_path/forwarding.config ]]; then
>>> >> source "$relative_path/forwarding.config"
>>> >> fi
>>> >>
>>> >> -source ../lib.sh
>>> >> +source ${lib_dir-.}/../lib.sh
>>> >> ##############################################################################
>>> >> # Sanity checks
>>> >
>>> > Hi Petr,
>>> >
>>> > Thanks for the report. However, this doesn't fix the soft link scenario. e.g.
>>> > The bonding tests tools/testing/selftests/drivers/net/bonding add a soft link
>>> > net_forwarding_lib.sh and source it directly in dev_addr_lists.sh.
>>>
>>> I see, I didn't realize those exist.
>>>
>>> > So how about something like:
>>> >
>>> > diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
>>> > index 8f6ca458af9a..7f90248e05d6 100755
>>> > --- a/tools/testing/selftests/net/forwarding/lib.sh
>>> > +++ b/tools/testing/selftests/net/forwarding/lib.sh
>>> > @@ -38,7 +38,8 @@ if [[ -f $relative_path/forwarding.config ]]; then
>>> > source "$relative_path/forwarding.config"
>>> > fi
>>> >
>>> > -source ../lib.sh
>>> > +forwarding_dir=$(dirname $(readlink -f $BASH_SOURCE))
>>> > +source ${forwarding_dir}/../lib.sh
>>>
>>> Yep, that's gonna work.
>>> I'll pass through our tests and send later this week.
>>
>> There is also another related issue which is that generating a test
>> archive using gen_tar for the tests under drivers/net/bonding does not
>> include the new lib.sh. This is similar to the issue reported here:
>> https://lore.kernel.org/netdev/40f04ded-0c86-8669-24b1-9a313ca21076@redhat.com/
>>
>> /tmp/x# ./run_kselftest.sh
>> TAP version 13
>> [...]
>> # timeout set to 120
>> # selftests: drivers/net/bonding: dev_addr_lists.sh
>> # ./net_forwarding_lib.sh: line 41: ../lib.sh: No such file or directory
>> # TEST: bonding cleanup mode active-backup [ OK ]
>> # TEST: bonding cleanup mode 802.3ad [ OK ]
>> # TEST: bonding LACPDU multicast address to slave (from bond down) [ OK ]
>> # TEST: bonding LACPDU multicast address to slave (from bond up) [ OK ]
>> ok 4 selftests: drivers/net/bonding: dev_addr_lists.sh
>> [...]
>
> The issue is that the symlink becomes a text file during install, and
> readlink on that file then becomes a nop. Maybe the bonding tests should
> include net/forwarding/lib.sh through a relative path like other tests
> in drivers/, instead of this symlink business?
Or wait, the goal is for make install in the bonding directory to
produce a working install, right?
Hmm.
This worked before exactly because the symlink became a text file.
It does not work in general, but it did work for bonding.
I don't have ideas how to solve this elegantly honestly.
Maybe have bonding tests set $net_lib_dir and forwarding/lib.sh then
source net/lib.sh through that path if set; have bonding symlink
net/lib.sh in addition to forwarding/lib.sh, and set net_lib=.?
It's ugly as sin, but... should work?
Hmm, maybe we could side-step the issue? I suspect that vast majority of
what bonding uses are just generic helpers. log_test, check_err, that
sort of stuff. Unless I missed something, all of them set NUM_NETIFS=0.
Those things could all be in the generic net/lib.sh. So long-term it
might be possible for bonding to do the trick with symlinking, except
with just net/lib.sh, not both libs.
I think that most of forwarding/lib.sh actually belongs to net/lib.sh.
We reinvent a lot of that functionality in various net/ tests, because,
presumably, people find it odd to source forwarding/lib.sh. If it all
lived in net/, we could reuse all these tools instead of cut'n'pasting
them from one test to the other. Stuff like the mcast_packet_test,
start/stop_traffic, etc., would probably stay in forwarding.
So that's long-term. And short-term we can live with the ugly-as-sin
workaround that I propose?
Ideas? Comments?
next prev parent reply other threads:[~2023-12-13 11:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-11 12:01 [PATCH net-next] selftests: forwarding: Import top-level lib.sh through $lib_dir Petr Machata
2023-12-11 12:44 ` Hangbin Liu
2023-12-12 17:22 ` Petr Machata
2023-12-12 20:17 ` Benjamin Poirier
2023-12-13 6:00 ` Hangbin Liu
2023-12-13 21:40 ` Benjamin Poirier
2023-12-14 7:06 ` Hangbin Liu
2023-12-14 22:00 ` Benjamin Poirier
2023-12-15 2:35 ` Hangbin Liu
2023-12-15 23:30 ` Benjamin Poirier
2023-12-21 16:58 ` Vladimir Oltean
2023-12-22 14:09 ` Benjamin Poirier
2023-12-13 10:03 ` Petr Machata
2023-12-13 10:31 ` Petr Machata [this message]
2023-12-14 6:57 ` Hangbin Liu
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=87y1dyl635.fsf@nvidia.com \
--to=petrm@nvidia$(echo .)com \
--cc=benjamin.poirier@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=jtoppins@redhat$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=liuhangbin@gmail$(echo .)com \
--cc=me@pmachata$(echo .)org \
--cc=mlxsw@nvidia$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=shuah@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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