Patch series "kmod/umh: a few fixes". Tiezhu Yang had sent out a patch set with a slew of kmod selftest fixes, and one patch which modified kmod to return 254 when a module was not found. This opened up pandora's box about why that was being used for and low and behold its because when UMH_WAIT_PROC is used we call a kernel_wait4() call but have never unwrapped the error code. The commit log for that fix details the rationale for the approach taken. I'd appreciate some review on that, in particular nfs folks as it seems a case was never really hit before. This patch (of 5): Use the variable NAME instead of "\000" directly in kmod_test_0001().
Unified · Split
| @@ -343,7 +343,7 @@ kmod_test_0001_driver() · 342 unmodified lines | ||
| 343 | 343 | |
| 344 | 344 | kmod_defaults_driver |
| 345 | 345 | config_num_threads 1 |
| 346 | − printf '\000' >"$DIR"/config_test_driver | |
| 346 | + printf $NAME >"$DIR"/config_test_driver | |
| 347 | 347 | config_trigger ${FUNCNAME[0]} |
| 348 | 348 | config_expect_result ${FUNCNAME[0]} MODULE_NOT_FOUND |
| 349 | 349 | } |
| @@ -354,7 +354,7 @@ kmod_test_0001_fs() · 4 unmodified lines | ||
| 354 | 354 | |
| 355 | 355 | kmod_defaults_fs |
| 356 | 356 | config_num_threads 1 |
| 357 | − printf '\000' >"$DIR"/config_test_fs | |
| 357 | + printf $NAME >"$DIR"/config_test_fs | |
| 358 | 358 | config_trigger ${FUNCNAME[0]} |
| 359 | 359 | config_expect_result ${FUNCNAME[0]} -EINVAL |
| 360 | 360 | } |