Revision Control Naming

The naming of the files which contain test case source code should embed the revision to which it targets compliance against in the filename. For example, a test which targets the creation of ASQ’s could have source code files of createAdminSubmissionQueue.{cpp | h}. And since it is possible for the requirements for the creation of these queues to change over time, it must be labeled to the specification to which is was coded, when developed. This would allow testing against a specific way of creating queues, i.e. the one in which a hardware vendor chose to adopt in their design.

The format of revision naming takes the form FILENAME**_r**NVMESTRING, where NVMESTRING is the exact string the NVMe Working Group uses to identify a particular revision less any punctuation. Thus specification release 1.0b will become “_r10b”. And in our prior example the filenames would become createAdminSubmissionQueue_r10b.{cpp | h}.

If it turns out that the creation of ASQ’s never change during the lifetime of the NVMe specification, then there will be no need to derive children based upon the source code createAdminSubmissionQueue_r10b.{cpp | h}. These original source code files will suffice for the lifetime of tnvme. If there exists files called createAdminSubmissionQueue_r34a.{cpp | h}, then this is clear indication that the creation of ASQ’s changed in some manner and that it did so in specification release 3.4a. This implies that the original files createAdminSubmissionQueue_r10b.{cpp | h} will be sufficient for all releases up to, but not including revision 3.4a. In light of this, it is easy to see that if one specified test case execution to comply with say revision 2.9a that the log files and output from tnvme would show compliance to 1.0b, which is to be expected since no change in ASQ creation occurring in 2.9a from that defined in 1.0b.

This naming convention makes it harder to see revision mismatch mistakes in the architecture because the command line specified revision may not exactly match that which shows up in the output from tnvme. However, this difficulty is acceptable when compared to the benefit of this approach. As each new NVMe specification is released we won’t be forced to derive from every single outstanding test case just too simply output that the same logic now applies to a subsequent revision for the purpose of visual satisfaction.