netdev - Re: [PATCH net-next 7/7] testing: net-drv: add a driver test for stats reporting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240402103111.7d190fb1@kernel.org>
Date: Tue, 2 Apr 2024 10:31:11 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Petr Machata <petrm@...dia.com>
Cc: <davem@...emloft.net>, <netdev@...r.kernel.org>, <edumazet@...gle.com>,
 <pabeni@...hat.com>, <shuah@...nel.org>, <sdf@...gle.com>,
 <donald.hunter@...il.com>, <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH net-next 7/7] testing: net-drv: add a driver test for
 stats reporting

On Tue, 2 Apr 2024 18:37:44 +0200 Petr Machata wrote:
> Yeah, this would be usually done through context managers, as I mention
> in the other e-mail. But then cfg would be lexically scoped, which IMHO
> is a good thing, but then it needs to be passed around as an argument,
> and that makes the ksft_run() invocation a bit messy:
> 
>     with NetDrvEnv(__file__) as cfg:
>         ksft_run([lambda: check_pause(cfg),
>                   lambda: check_fec(cfg),
>                   lambda: pkt_byte_sum(cfg)])
> 
> Dunno, maybe it could forward *args **kwargs to the cases? But then it
> loses some of the readability again.

Yes, I was wondering about that. It must be doable, IIRC 
the multi-threading API "injects" args from a tuple.
I was thinking something along the lines of:

    with NetDrvEnv(__file__) as cfg:
        ksft_run([check_pause, check_fec, pkt_byte_sum],
                 args=(cfg, ))

I got lazy, let me take a closer look. Another benefit
will be that once we pass in "env" / cfg - we can "register" 
objects in there for auto-cleanup (in the future, current
tests don't need cleanup)