On Mon, Feb 10, 2025 at 11:35:48AM -0800, John Hubbard wrote:
On 2/9/25 11:54 PM, Geert Uytterhoeven wrote:
On Sat, 8 Feb 2025 at 18:53, Yury Norov <yury.norov@xxxxxxxxx> wrote:
On Fri, Feb 07, 2025 at 03:14:01PM -0500, Tamir Duberstein wrote:
On 7/27/24 12:35 AM, Shuah Khan wrote:
...
The crux of the argument seems to be that the config help text is taken
to describe the author's intent with the fragment "at boot". I think
IMO, "at boot" is a misnomer, as most tests can be either builtin
or modular.
Right.
KUNIT is disabled in defconfig, at least on x86_64. It is also disabled
on my Ubuntu 24.04 machine. If I take your patches, I'll be unable to
OK so I just bought a shiny new test machine, and installed one of the
big name distros on it, hoping they've moved ahead and bought into the kunit
story...
$ grep KUNIT /boot/config-6.8.0-52-generic
# CONFIG_KUNIT is not set
...gagghh! No such luck. One more data point, in support of Yuri's complaint. :)
I think distros should start setting CONFIG_KUNIT=m.
Yes they should! kunit really does have important advantages for many use
cases, including bitmaps here, and "CONFIG_KUNIT is not set" is the main
obstacle.
Hi John, Geert, Tamir,
Can you please explain in details which advantages KUNIT brings to
the test_bitmap.c, find_bit_benchmark.c and other low-level tests?
I'm not strongly against moving under KUNIT's hat, but I do:
- respect commitment of my contributors, so I don't want to wipe git
history for no serious reason;
- respect time of my testers, so no extra dependencies;
- respect time of reviewers.
Tamir,
If it comes to v2, can you please begin your series with an exhaustive
and clear answer to the following questions:
- What do the tests miss now?
- What do _you_ need from the tests? Describe your test scenario.
- How exactly KUNIT helps you testing bitmaps and friends better?
- Is there a way to meet your needs with a less invasive approach,
particularly without run-time dependencies?
Thanks,
Yury
