On 2025-10-15 2:46 pm, Robin Murphy wrote:
kunit_device_register() only returns error pointers, not NULL. Furthermore for regular users who aren't testing the KUnit API itself, errors most likely represent major system failure (e.g. OOM or sysfs collision) beyond the scope of their own test conditions. Replace the assert with straightforward error handling for clarity.
Signed-off-by: Robin Murphy robin.murphy@arm.com
This seemed the logical conclusion by inspection, but please do correct me if I've misunderstood the intent...
Documentation/dev-tools/kunit/usage.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 038f480074fd..3452c739dd44 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -873,7 +873,8 @@ For example: // Create a fake device. fake_device = kunit_device_register(test, "my_device");
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fake_device)
if (IS_ERR(fake_device))return;
On further consideration, I guess kunit_skip() (as used in various other places) is actually what I want here?
Basically, as someone looking at KUnit with fresh eyes it seems intuitive to me that not being able to run a test case is a not a failure of the thing being tested, so shouldn't be reported as such, and thus this example stood out. I for one wouldn't want to be getting CI notifications to go and debug a "regression" in my code just because a runner OOM'd, for example :)
Thanks, Robin.
// Pass it to functions which need a device. dev_managed_string = devm_kstrdup(fake_device, "Hello, World!");