[Intel-gfx] [PATCH 08/10] lib: Introduce drmtest_skip_on_simulation()

Jesse Barnes jbarnes at virtuousgeek.org
Tue Apr 30 01:00:31 CEST 2013


On Mon, 29 Apr 2013 19:15:35 +0100
Damien Lespiau <damien.lespiau at intel.com> wrote:

> This will allow us to explicitely blacklist tests we don't want to run
> on simulation.
> 
> Signed-off-by: Damien Lespiau <damien.lespiau at intel.com>
> ---
>  lib/drmtest.c | 12 ++++++++++++
>  lib/drmtest.h |  1 +
>  2 files changed, 13 insertions(+)
> 
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 6e5b636..cafc8bc 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -38,6 +38,7 @@
>  #include <math.h>
>  #include <getopt.h>
>  #include <stdlib.h>
> +#include <unistd.h>
>  
>  #include "drmtest.h"
>  #include "i915_drm.h"
> @@ -612,6 +613,17 @@ bool drmtest_run_in_simulation(void)
>  	return simulation;
>  }
>  
> +/* Skip the test when running on simulation (and that's relevant only when
> + * we're not in the mode where we list the subtests) */
> +void drmtest_skip_on_simulation(void)
> +{
> +	if (drmtest_only_list_subtests())
> +		return;
> +
> +	if (drmtest_run_in_simulation())
> +		exit(77);
> +}
> +
>  /* other helpers */
>  void drmtest_exchange_int(void *array, unsigned i, unsigned j)
>  {
> diff --git a/lib/drmtest.h b/lib/drmtest.h
> index 71d68c4..96dddda 100644
> --- a/lib/drmtest.h
> +++ b/lib/drmtest.h
> @@ -91,6 +91,7 @@ bool drmtest_only_list_subtests(void);
>  
>  bool drmtest_run_in_simulation(void);
>  #define SLOW_QUICK(slow,quick) (drmtest_run_in_simulation() ? (quick) : (slow))
> +void drmtest_skip_on_simulation(void);
>  
>  /* helpers based upon the libdrm buffer manager */
>  void drmtest_init_aperture_trashers(drm_intel_bufmgr *bufmgr);

So if we're shooting for a real test suite in the end, this seems like
the wrong way to go.  Rather we should be pulling boilerplate *out* of
each test (like open_any, sanity checks for ppgtt or whatever) and
making each test tiny.

Then we could have lists of tests in a separate file, complete with
parameters, that would define specific areas of interest or things to
run.

I'm hoping that wouldn't get in the way of running individual tests
easily, but I don't think it would if we did it right...

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list