Quoting Tvrtko Ursulin (2018-09-07 12:14:20) > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > Proposal to add test tags as a replacement for separate test > list which can be difficult to maintain and get out of date. > > Putting this maintanenace inline with tests makes it easier > to remember to update the (now implicit) lists, and also enables > richer test selection possibilities for the test runner. > > Current method of implying tags from test/subtest names has a > couple of problems one of which is where some names can use > the same token for different meanings. (One example is the > "default" token.) It also creates a name clash between naming > and tagging. > > Test tags are strings of tokens separated by spaces, meaning of > which we decide by creating a convetion and helped by the > suitable helper macros. > > For example tags can be things like: gem, kms, basic, guc, flip, > semaphore, bz12345678, gt4e, reset, etc.. > > At runtime this would look something like this (abbreviated for > readability): > > @ tests/gem_sync --list-subtests-with-tags > ... > forked-each TAGS="gem " > forked-store-each TAGS="gem " > basic-all TAGS="gem basic " > basic-store-all TAGS="gem basic " > > @ tests/gem_concurrent_blit --list-subtests-with-tags > ... > 16MiB-swap-gpuX-render-write-read-bcs-bomb TAGS="gem stress " > 16MiB-swap-gpuX-render-write-read-rcs-bomb TAGS="gem stress " > 16MiB-swap-gpuX-render-gpu-read-after-write-bomb TAGS="gem stress " > > @ tests/kms_flip --list-subtests-with-tags | grep basic > basic-plain-flip TAGS="kms basic " > basic-flip-vs-dpms TAGS="kms basic " > > Test runner could then enable usages like: > > ./run-tests --include gem --exclude stress Minor comment, I like some basic boolean algebra here --include "gem AND smoketest NOT stress" :) I'd probably tag everything according to which ioctls they use. I feel my endgoal is still to list tests by their kernel functions (which can and should be automatically derived), and their hw function which is the open problem. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx