Design Strategy

The strategy of design for NVMe compliance is to create a framework to facilitate an easy interface to create test cases, but still allow the greatest flexibility to inject illegal conditions and states. Testing a hardware API might warrant kernel mode test cases to allow the most insight into what is occurring at the hardware level. However, this approach has a few inherent complications:

1. Kernel mode programming is not very forgiving in that a mistake could cause the kernel to panic. Investigating these occurrences is usually not simple.
2. Not all developers understand the intricacies of kernel mode programming
3. Developing tests still requires a user space application to drive the logic and thus to add a test two modules would most likely need to be touched.

Therefore this design sought to keep the kernel level modifications to a minimum. And so the kernel component, dnvme, can be thought of as a conduit to pipe functionality to user space where the real orchestration will occur by tnvme. tnvme must then seek to wire functional components together, in effect directing the Device Under Test (DUT) to perform desired actions. The results of those actions are determined success or failure by tnvme to conclude NVMe compliance. The wiring of components boils down to sending IOCTL’s into dnvme.

This approach however will most likely not become the 100% solution and fail to allow complete testing of NVMe compliance. However it is expected that any possible short coming will be in the minority and a hybrid approach could address this. In other words, some tests may have to locate within dnvme. They will most likely take the form of canned test cases, be launched by tnvme, and yield a simple success or failure as determined by dnvme. The design of dnvme has tried to address this expectation by modularizing the logic into discrete components. The hope is that the same logical functions can be reused within the kernel to achieve testing these requirements.