This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: tapset quality
- From: Kris Van Hees <kris dot van dot hees at oracle dot com>
- To: systemtap at sources dot redhat dot com
- Date: Thu, 30 Aug 2007 13:28:44 -0400
- Subject: Re: tapset quality
- References: <20070830170518.GC20477@redhat.com>
On Thu, Aug 30, 2007 at 01:05:18PM -0400, Frank Ch. Eigler wrote:
> Will Cohen's script coverage code in the translator lets one identify
> which parts of the tapset are not even compiled. We need someone to
> bootstrap an ongoing process to take this data and create some buildok
> tests for as many of them as possible. Any volunteers, please? If
> the coverage generator is fast enough now to keep it on, I'll change
> the test suite to report on its own coverage at the conclusion of a
> test run.
This ties in nicely in the work I have been doing to get 'labrat' (the
automated build-and-test system) ready for systemtap reporting.
The things I am working on are:
- Determine the minimal amount of data to be added to the testsuite output
in order to satisfy the reporting requirements for labrat. This is a
somewhat temporary step, because once labrat is fully capable of dealing
with kernel level testing (i.e. handle crashes and such in a useful way)
it will no longer be needed (it will be done by the client driver script).
This is done (I'll post another email about that shortly, and I'll ask
Wenji to create a patch for it).
- Interpretation of the tapset coverage data that Will Cohen's code tracks.
This is a work in progress. Right now, I almost have the data in a format
that I can use to get lcov-alike output.
- Scripting on the labrat reporting server to take output from the testsuite
runs done by various people, and feed them into the reporting structure.
With the extra data added to it, the systemtap.log output ought to be
sufficient (since it is very verbose anyway).
Cheers,
Kris