[Ksummit-discuss] [CORE TOPIC] Testing
Peter Hüwe
PeterHuewe at gmx.de
Tue Jul 7 22:51:41 UTC 2015
Hi,
I definitely think discussing the next steps in terms of automated regression
testing is important - so thanks for raising this issue!!
> >> Maybe list all known ones as a start ?
> >
> > Off the top of my head the automated ones I'm aware of are Olof's build
> > & boot test, Dan running smatch and I think some other static analysis
> > stuff, someone (not sure who?) running some coccinelle stuff, Coverity
> > and I've got a builder too.
For the TPM subsystem I have several things in place:
- applying patches automatically triggers a build on travis-ci.org
-- it triggers some basic style checkers
-- the build runs a qemu (with the tpm simulator) running another qemu (which
now sees a real /dev/tpm0) with the new kernel.
--- the qemu-qemu-linux runs my tpm driver testsuite.
The reason behind this is that I can hook up besides the TPM1.2 simulator also
the binary only windows based TPM2.0 simulator (with wine) without modifying
qemu source -- but still the qemu-qemu-kernel sees 'real' hardware.
- some scripts for deploying new kernels to real hw machines and running tests
with real hw tpms
- a mocked i2c tpm which I can hook up via the I2C_Slave interface, which also
passes my driver testsuite -- so I can test the drivers within UML :)
- and of course wolfram's ninja-check scripts for style checkers
> Plus mine, of course. Only part missing is automated bisect and e-mail
> if something starts failing.
Yeah - getting the reports reasonably fast is probably the most important
stuff -- the 0day testing really does a great job here.
Thanks,
Peter
More information about the Ksummit-discuss
mailing list