Re: [PATCH net-next 1/5] selftests: drv-net: define endpoint structures

[Petr Machata <me@pmachata.org>]

Willem de Bruijn <willemdebruijn.kernel@gmail.com> writes:

> 1. Cleaning up remote state in all conditions, including timeout/kill.
>
>    Some tests require a setup phase before the test, and a matching
>    cleanup phase. If any of the configured state is variable (even
>    just a randomized filepath) this needs to be communicated to the
>    cleanup phase. The remote filepath is handled well here. But if
>    a test needs per-test setup? Say, change MTU or an Ethtool feature.
>    Multiple related tests may want to share a setup/cleanup.

Personally I like to wrap responsibilities of this sort in context
managers, e.g. something along these lines:

    class changed_mtu:
        def __init__(self, dev, mtu):
            self.dev = dev
            self.mtu = mtu

        def __enter__(self):
            js = cmd(f"ip -j link show dev {self.dev}", json=True)
            self.orig_mtu = something_something(js)
            cmd(f"ip link set dev {self.dev} mtu {self.mtu}")

        def __exit__(self, type, value, traceback):
            cmd(f"ip link set dev {self.dev} mtu {self.orig_mtu}")

    with changed_mtu(swp1, 10000):
       # MTU is 10K here
    # and back to 1500

A lot of this can be made generic, where some object is given a setup /
cleanup commands and just invokes those. But things like MTU, ethtool
speed, sysctls and what have you that need to save a previous state and
revert back to it will probably need a custom handler. Like we have them
in lib.sh as well.