On Tue, 2024-01-23 at 08:45 -0800, Jakub Kicinski wrote:
On Mon, 22 Jan 2024 15:34:34 +0000 (UTC) Kalle Valo wrote:
Lukas Bulwahn (1): wifi: cfg80211/mac80211: remove dependency on non-existing option
BTW we run all kernel's kunit tests on netdev periodically by doing:
./tools/testing/kunit/kunit.py run --all
and AFAICT the WiFi tests don't pop up there :(
https://netdev.bots.linux.dev/contest.html?branch=net-next-2024-01-23--15-00...
Is that on purpose?
No, but honestly, I didn't even really know about it, which is mostly for lack of bothering to look - because we run them in a different way now both in upstream hostap and internally (internally we also have another file with metadata to tie them to other bits of the whole project that isn't interesting upstream).
Looks like that needs adjustments to the config file there, mostly? I can see about adding that, probably not that hard, at least for mac80211/cfg80211.
++kunit folks:
We're also adding unit tests to iwlwifi (slowly), any idea if we should enable that here also? It _is_ now possible to build PCI stuff on kunit, but it requires some additional config options (virt-pci etc.), not sure that's desirable here? It doesn't need it at runtime for the tests, of course.
johannes
On Tue, 2024-01-23 at 19:19 +0100, Johannes Berg wrote:
We're also adding unit tests to iwlwifi (slowly), any idea if we should enable that here also? It _is_ now possible to build PCI stuff on kunit, but it requires some additional config options (virt-pci etc.), not sure that's desirable here? It doesn't need it at runtime for the tests, of course.
Heh, in fact Miri just posted the first bits:
https://lore.kernel.org/r/20240123200528.a4a8af7c091f.I0fb09083317b331168b99...
Also, should enabling that in tools/testing/kunit/configs/all_tests.config go through our tree, or better through the kselftest tree?
johannes
On Wed, 24 Jan 2024 at 02:22, Johannes Berg johannes@sipsolutions.net wrote:
On Tue, 2024-01-23 at 19:19 +0100, Johannes Berg wrote:
We're also adding unit tests to iwlwifi (slowly), any idea if we should enable that here also? It _is_ now possible to build PCI stuff on kunit, but it requires some additional config options (virt-pci etc.), not sure that's desirable here? It doesn't need it at runtime for the tests, of course.
Heh, in fact Miri just posted the first bits:
https://lore.kernel.org/r/20240123200528.a4a8af7c091f.I0fb09083317b331168b99...
Also, should enabling that in tools/testing/kunit/configs/all_tests.config go through our tree, or better through the kselftest tree?
I'd definitely like the iwlwifi tests to be enabled in all_tests.config.
The virt-pci options _should_ already be enabled for the UML configs under kunit.py by default now (they're in .../configs/arch_uml.config).
I don't mind which tree the changes to all_tests.config go through -- I suspect it's probably better for them to go in via your tree, particularly if they end up depending on any new config options.
-- David
On Tue, 23 Jan 2024 19:19:35 +0100 Johannes Berg wrote:
Looks like that needs adjustments to the config file there, mostly? I can see about adding that, probably not that hard, at least for mac80211/cfg80211.
To be clear I was mostly thinking about mac80211/cfg80211...
We're also adding unit tests to iwlwifi (slowly), any idea if we should enable that here also? It _is_ now possible to build PCI stuff on kunit, but it requires some additional config options (virt-pci etc.), not sure that's desirable here? It doesn't need it at runtime for the tests, of course.
but curious to hear about driver testing recommendations.
On Tue, 2024-01-23 at 13:42 -0800, Jakub Kicinski wrote:
We're also adding unit tests to iwlwifi (slowly), any idea if we should enable that here also? It _is_ now possible to build PCI stuff on kunit, but it requires some additional config options (virt-pci etc.), not sure that's desirable here? It doesn't need it at runtime for the tests, of course.
but curious to hear about driver testing recommendations.
Not sure I have any recommendations ... The test we posted is checking an invariant (the devinfo array is sorted in the right way); we used to have a check for this in the internal driver variant at init time, now it's a kunit test and we don't have to carry the delta to upstream here.
I think Miri is also working on some additional tests for some driver- internal logic though.
So not sure, I guess it'd be just like anything else you could use unit testing for, certain self-contained parts of the code that don't really otherwise need a device, etc.?
johannes
linux-kselftest-mirror@lists.linaro.org
-
David Gow -
Jakub Kicinski -
Johannes Berg