Re: [Ksummit-discuss] [CORE TOPIC] Testing

["Peter Hüwe" <PeterHuewe@gmx.de>]

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