[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