On 7/19/19 8:51 PM, Joe Lawrence wrote:
On 7/19/19 6:11 PM, shuah wrote:
On 7/14/19 8:33 AM, Joe Lawrence wrote:
On Sun, Jul 14, 2019 at 10:28:29AM -0400, Joe Lawrence wrote:
[ ... snip ... ]
Testing:
Here's the output if modprobe --dry-run doesn't like the modules (not built, etc.):
TAP version 13 selftests: livepatch: test-livepatch.sh ======================================== SKIP: Failed modprobe --dry-run of module: test_klp_livepatch not ok 1..1 selftests: livepatch: test-livepatch.sh [SKIP] selftests: livepatch: test-callbacks.sh ======================================== SKIP: Failed modprobe --dry-run of module: test_klp_callbacks_demo not ok 1..2 selftests: livepatch: test-callbacks.sh [SKIP] selftests: livepatch: test-shadow-vars.sh ======================================== SKIP: Failed modprobe --dry-run of module: test_klp_shadow_vars not ok 1..3 selftests: livepatch: test-shadow-vars.sh [SKIP]
Please refine these messages to say what users should do. In addition to what failed, also add what is missing - enable config option etc.
Hi Shuah,
Note that v2 was posted [1], but the output remains basically the same, so your comments still apply.
Off the top of my head, modprobe can fail for many reasons: unprivileged user, missing .ko files, missing modules.dep entry, kernel vermagic, interface versions, etc.
What would you think about modifying our skip() function to provide a catch-all list of CONFIG, environment, etc. requirements? Something like, "Please ensure that the kernel was build with CONFIG_XYZ and that the tests are run with foo privileges"? That would let us avoid trying to figure out exactly why the modprobe failed, but still help out the user.
I understand. I am not suggesting that you have to figure out why. I am suggesting that instead of "Failed modprobe --dry-run of module", say "Unable to load test_klp_shadow_vars module. Check if config option is enabled" which is user friendly compared to the current message.
thanks, -- Shuah