netdev - Re: [PATCH net] selftests: drv-net: make linters happy with our imports

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] [day] [month] [year] [list]

Message-ID: <20251002161450.GA2873873@horms.kernel.org>
Date: Thu, 2 Oct 2025 17:14:50 +0100
From: Simon Horman <horms@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
	pabeni@...hat.com, andrew+netdev@...n.ch, petrm@...dia.com
Subject: Re: [PATCH net] selftests: drv-net: make linters happy with our
 imports

On Wed, Oct 01, 2025 at 04:43:08PM -0700, Jakub Kicinski wrote:
> Linters are still not very happy with our __init__ files,
> which was pointed out in recent review (see Link).
> 
> We have previously started importing things one by one to
> make linters happy with the test files (which import from __init__).
> But __init__ file itself still makes linters unhappy.
> 
> To clean it up I believe we must completely remove the wildcard
> imports, and assign the imported modules to __all__.
> 
> hds.py needs to be fixed because it seems to be importing
> the Python standard random from lib.net.
> 
> We can't use ksft_pr() / ktap_result() in case importing
> from net.lib fails. Linters complain that those helpers
> themselves may not have been imported.
> 
> Link: https://lore.kernel.org/9d215979-6c6d-4e9b-9cdd-39cff595866e@redhat.com
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> ---
> Sending a fix for the driver's __init__.py first, if this is okay
> with everyone I'll convert the rest. I'm not super confident 'cause
> my Python isn't properly learned.
> 
> Sending for net, even tho its not a real fix. I think that getting
> it applied during the merge window may be okay? No strong prefence.
> I'm slightly worried that merging it in net-next after the MW will
> leave us with a release cycle full of merge conflicts.

It looks like we are off to a flying start on that front:
it seems this does not apply cleanly to net.

...