[Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

Chris Wilson chris at chris-wilson.co.uk
Mon Mar 13 15:06:41 UTC 2017


On Mon, Mar 13, 2017 at 04:29:47PM +0200, Petri Latvala wrote:
> On Mon, Mar 13, 2017 at 02:15:34PM +0000, Chris Wilson wrote:
> > On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote:
> > > On Mon, Mar 13, 2017 at 10:50:04AM +0000, Chris Wilson wrote:
> > > > Still completely lacking justification. The above is a non sequitur;
> > > > static testlist generation can be done just from the source.
> > > 
> > > Static testlist generation can be done and it breaks when run on a
> > > kernel without selftests enabled.
> > 
> > That doesn't make sense. static is a static list, as simple as using sed
> > on the headers.
> 
> Without this series, having the selftests in a .testlist with piglit results in
> 
>  KeyError: 'igt at drv_selftest@mock_sanitycheck'
> 
> et al.
> 
> "But we can fix piglit to ignore that error!"
> 
> Sure, and that's on the way, but we're not there yet.
> 
> Then when we add testlist checking to IGT to notify developers that
> the test they removed/renamed was in a testlist file and the testlist
> should be edited, we also hardcode drm_mm, drv_selftest and
> $whatever-is-in-future to not be checked?
> 
> When generating documentation, we ignore that the docs for drm_mm and
> drv_selftest generate different documents depending on where they are
> built?
> 
> We also hardcode igt_command_line.sh to ignore errors with drm_mm and
> drv_selftest?

Nope. jst igt_comand_line.sh is enforcing a workaround for piglit that
does not affect igt itself.
 
> Or, just maybe, we could follow the convention of having subtest
> enumeration always work regardless of environment, by always exposing
> certain test names?

Go read the tests and see how broken that concept is.
 
> Why the rules don't apply to kselftest launchers?

What rules? All I see above is piglit is broken. Why should we
workaround bugs in piglit?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list