[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y1dyl635.fsf@nvidia.com>
Date: Wed, 13 Dec 2023 11:31:50 +0100
From: Petr Machata <petrm@...dia.com>
To: Petr Machata <me@...chata.org>
CC: Benjamin Poirier <benjamin.poirier@...il.com>, Petr Machata
<petrm@...dia.com>, Hangbin Liu <liuhangbin@...il.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, <netdev@...r.kernel.org>,
Shuah Khan <shuah@...nel.org>, <mlxsw@...dia.com>, Jonathan Toppins
<jtoppins@...hat.com>
Subject: Re: [PATCH net-next] selftests: forwarding: Import top-level lib.sh
through $lib_dir
Petr Machata <me@...chata.org> writes:
> Benjamin Poirier <benjamin.poirier@...il.com> writes:
>
>> On 2023-12-12 18:22 +0100, Petr Machata wrote:
>>>
>>> Hangbin Liu <liuhangbin@...il.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?
Powered by blists - more mailing lists