On 11/23/2017 09:20 AM, Dong Jia Shi wrote: > * Halil Pasic <[email protected]> [2017-11-08 17:54:20 +0100]: > > Hi Halil, > >> Add a fake device meant for testing the correctness of our css emulation. >> >> What we currently have is writing a Fibonacci sequence of uint32_t to the >> device via ccw write. The write is going to fail if it ain't a Fibonacci >> and indicate a device exception in scsw together with the proper residual >> count. With this we can do basic verification of data integrity. >> >> Of course lot's of invalid inputs (besides basic data processing) can be >> tested with that as well. >> >> We also have a no-op mode where the device just tells all-good! This >> could be useful for fuzzing. >> >> Usage: >> 1) fire up a qemu with something like -device ccw-testdev,devno=fe.0.0001 >> on the command line >> 2) exercise the device from the guest >> >> Signed-off-by: Halil Pasic <[email protected]> >> --- >> >> Introduction >> ------------ >> >> While discussing v1 we (more or less) decided a test device for ccw is a >> good idea. This is an RFC because there are some unresolved technical >> questions I would like to discuss. >> > Regarding to test coverage, this mainly covers the cds_read.
This series has only a linux module with some texts and is more of a PoC than the way it should be done. I think I wrote somewhere about this. The ccw-testdev being mainly about cds_read is not correct. See the TIC must have zero count test in patch 3. The cds things only become relevant if data matters for the test. The ccw-testdev is about making it possible to check how does the channel subsystem respond to certain stimuli without actually having to care about a real device. > What we > want would be surely more than this. So to extend the coverage, we need > to design more modes (aka, test cases), right? Modes and testcases are not the same. See patches 2 and 3. Modes are mostly for being extensible in a sense of expect the unexpected. I don't have too may ideas for modes (one more I can think of could be some tee like proxy for doing whatever kind of assertions/analysis on what some driver does). In the previous round we said we want this extensible, and it make sense. > > If nobody disagrees with the basic idea of this series, I can start a > review then. ;) > > [...] >
