Re: Tests that require 'modprobe <module>'

[Mike Mason <mmlnx at us dot ibm dot com>]

Stone, Joshua I wrote:
> Mike Mason wrote:
> > I'd like to add some tests that require certain modules be inserted
> > (specifically nfs & rpc).  Where's the best place in the test
> > framework to do modprobe?
>
> First, using 'modprobe' requires root access.  Most of 'make
> installcheck' only needs the stapdev group, with the exception of a few
> tests that use sudo.  I would like to see us reduce the root requirement
> more...

I understand the desire to reduce the root requirement for users, but for
complete testing that may be unrealistic.

> But anyway, a test requiring specific modules is bound to be fragile.
> What happens if that module was instead built into the kernel, or not
> built at all?  Or if it is a module and you successfully load it, it
> clearly wasn't in use, so how can you test any probes within?

I was thinking the modprobe would simply fail if the code is built 
into the kernel instead.  There's no harm silently ignoring that
as far as I can tell.  If the code isn't in the kernel and isn't built 
as a module, the tests for those probe points should fail.  I know, the
test didn't actually run and fail, we just failed to test.  To me, that's 
still a failure.

As for whether the module's in use, in some cases that doesn't matter.
For example, you can still load the nfs, nfsd and sunrpc modules and
run build tests against them even though they're not being used.  This
may not be true for all modules.

> Can you instead write your test to gracefully skip if the module isn't
> present?  (It shouldn't record a failure...)

I don't think untested tapsets should be silently ignored.  If we don't
figure out how to test *everything*, even if it's hard, how will we
know when some change in the kernel breaks a tapset?  When a 
systemtap user stumbles on the problem?  IMHO, that's
unacceptable.

Mike

> Josh