Re: [RFC] Smattering of selftests

[Paulo Zanoni <paulo.r.zanoni@intel.com>]

Em Qua, 2016-12-07 às 13:58 +0000, Chris Wilson escreveu:
> More changes to GEM are on the cards, so before touching it again,
> let's
> try and nail down how the internals are meant to work. The advantage
> of mock testing is that we can write a universal test independent of
> the
> hw (e.g. testing physical object creation) and we can inspect
> internal
> state which should be able to spot subtle bugs easier than mashing
> the
> uabi. The downside to mock testing is that it doubles the upfront
> cost
> of every patch submission (if you change internal state, you're
> likely
> going to upset a test) and adds maintainance burden tracking change
> to
> external API (on the other hand it catches those silent changes that
> would lead to broken code).
> 
> In addition to mock tests, I thought it would be useful to start
> writing
> a few run-once tests against real hardware. These are not as
> interesting
> as probing uabi (I don't envisage having kms_flip inside the kernel),
> but we might like to exercise runtime suspend once upon startup, for
> example. Again, we have access to internal state that may prove
> impossible to capture even in debugfs.
> 
> Is this a totally insane and impractical proposal?

In case my opinion matters to anyone, I really like the idea of kernel-
side tests. There's a limit to what we can do from user space, and the
Kernel even has self-tests for other modules, so we have a precedent
here. Also, in the past I did have some ideas for kernel-side test code
that I never implemented since we didn't have this infrastructure (I
forgot what were my ideas). I'd love to be able to contribute to this
when I have appropriate ideas.

Can we somehow make passing these tests a requirement for the CI system
too?

Now, I haven't looked at the specific tests you proposed, so I'm not in
the position to judge sanity in those specific tests. I'm also assuming
that DRM_I915_SELFTESTS=n will keep performance the same as before.

> -Chris
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx