Re: [PATCH net-next] selftests: forwarding: Import top-level lib.sh through $lib_dir

[Petr Machata <petrm@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?