Re: Ceph code coverage integration proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/02/2011 11:05 AM, Tommi Virtanen wrote:
<snip>
Proposal:

- add autoconf flag --enable-coverage, or some such (afaik Josh has
   this already), that compiles with coverage recording

This is in the wip_gcov branch as --with-gcov.

- get "make check" to record coverage for unit tests and clitests,
   do something to analyze those nicely (separate make target to avoid
   automake brain damage?)

- get "make install" to install the *.gcno to usr/local/ceph/coverage
   or such (no need to even create the directory if not --enable-coverage)

- add src/ceph-coverage.in:

--8<--
#!/bin/sh
set -e

export GCOV_PREFIX_STRIP=@@GCOV_PREFIX_STRIP@@

usage () {
       printf '%s: usage: %s OUTPUTDIR COMMAND [ARGS..]\n' "$(basename "$0")" "$(basename "$0")" 1>&2
       exit 1
}

export GCOV_PREFIX="$1"
[ -n "$GCOV_PREFIX" ] || usage
shift

case "$GCOV_PREFIX" in
     /*)
	# absolute path ->  ok
	;;
     *)
	# make it absolute
	GCOV_PREFIX="$PWD/$GCOV_PREFIX"
	;;
esac

exec "$@"
--8<--

   and get Makefile.am to create ceph-coverage out of that; substitute
   @@GCOV_PREFIX_STRIP@@ at build time with value of "$(pwd|tr -dc /|wc -c)"
   and install the script to usr/local/bin/ceph-coverage

- make integration tests run everything interesting as
   "/blah/blah/usr/local/bin/ceph-coverage /blah/coverage /blah/blah/usr/local/bin/cosd ..."
   do this even when not profiling, just to have the same code path always

- get another gitbuilder (just x86_64 i guess) to build with
   --enable-profile; individual test runs can use ceph binary tarball
   url to get the profiling builds

... and this is where it gets sketchy ...

- FAILED IDEA: make integration tests post-process the gcov data to
   *.{c,cc,...}.gcov etc

   PROBLEM: this means test box would need the source on it?? this has
   previously not been true

   BETTER: postprocess them elsewhere, like the place where we want
   to draw pretty charts and aggregate data across runs? unclear.. but
   if we archive the *.gcno, *.gcda, and can re-checkout the source, we
   can always come back to this later

This all sounds good.

- UNCLEAR: do we want to archive the *.gcno, *.gcda files, or just the
   *.{c,cc,...}.gcov?

- SUGGESTION: archive *.gcno (inside the ceph binary tarball), *.gcda,
   and git sha1 for now (the same way as e.g. log files from a test are
   archived); don't automate post-processing right now; can rsync an
   archive dir from the archive server, checkout right source tree, run
   manually, and see things work right; come back to this when the
   above works

This seems to be the way to go so we can change our post-processing later.

Josh
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux