CVT Project
Project to track status and features for the deos653cvt and registry-cvt development
Tasks
Initial Budget: TBD
TTD: TBD Hours
Current ETC: TBD hours
Current EAC: TBD hours
Non Labor: $TBD
| Delivery | Due Date | Estimated Delivery | Delivered | Percentage Complete |
|---|---|---|---|---|
| Release | 2014-05-31 | 2014-05-31 | 2014-05-31 | ?% |
Useful Links
- Query of deos-653-cvt outstanding PCRs
- Query of registry-cvt outstanding PCRs
- Query of ioi-cvt outstanding PCRs
Timesite Codes
2120-204-654
Overview
We are required to deliver a deos653 cvt and an integration tool cvt (which is a superset of the regcheck-python funcitonality). Changes to the IT and 653-config tool should be expected, as additional metadata be needed by the cvts.
High level requirements:
- One CVT tool version for all released component versions. The ioi-cvt currently follows this pattern. The latest ioi-cvt supports all released versions of the ioiapi library. To do this, the ioi-cvt has a 'binstruct_x_y.py' module that describes the binary layout of schema x and cvt schema y. A cvt also has a schema in case there is a change to the binary layout (additional cvt data) but no change in the struct type seen by the associated component.
- The source of validation rules is (generally) embedded in the components C struct. This is true for the ioiapi library and the 653 runtime library, and not true for the deos registry which contains DRC trace tags throughout the kernel source code.
- The customer expectation is that the CVT confirms:
- the content of the binary file is appropriate for the component (wont break it)
- the regeneration of the XML should match or be easily diffable to the original input XML file(s), with the implication being that the component is configured according to the users XML specification.
deos-653-cvt
In the SOW, this is what we told Honeywell we would deliver: slide 7. The 653 configuration tool generates a binary file to be used on target, but much of the 653 configuration data manifests itself in the IOI and registry binary files. deos-653-cvt will accept IOI, 653, and registry binary files on the command line. The cvts need to be architected in a way that they can svn:externals a means of extracting data from binary files.
ioi-cvt
Although not part of the SOW, *consider* changes here to have a consistent philosophy. The ioi-cvt generates IT XML to create memory objects and grant access rights to those memory objects. The registry content is not checked by the ioi-cvt to confirm the settings are as the user specified. Going forward, we believe it is necessary for a CVT to ensure all aspects of the requested configuration are "as specified".
registry-cvt
There is some CVT data in the Deos registry already, but that data has not been maintained for several kernel versions. The most difficult task here is in handling .fp.xml files. There is a mechanism in the IT already that creates a stack of executed feature provider actions, but that may or may not be complete. GK: Cronk has some alternative FP strategies.
Developer Environment
Want to be a developer? You'll need to rig active state python 2.7 and install some other open source python packages to be about to bootstrap && configure && make dist . Just install all the stuff here, starting with active state python. Before you build, read the components' README file
Where are these CVTs in svn
Tasks For deos653cvt
| Task | Assignee | Notes | Current Estimate |
|---|---|---|---|
| [1] Complete XML restoration CustomIOFunction size delta field. | GK Done | 2 | |
| [2] Review HM verification | Concerned that XML regeneration may overly rely on CVT data. If so, need logic to confirm XML specified behavior matches configured behavior. Preconditions are satisfied. | 8 | |
| [3] Qualification test suite check .t | GK Done | Test suite environment 'check' need to generate and diff .t files from IOI and registry binaries to the can files to ensure the environment is proper. Update: Decided to not do this step. Precondition on 653cvt is qualified ioi and registry CVTs. Those qualifications include testing their .r file content. This step is not necessary. | 2 |
| [4] DO-178C | ML | TQD updates, trace matrix generation, | ?? |
| [5] Doc review | Someone should read the UG, TQD, and release notes to ensure everything is in order | 8 | |
| [6] Post-fp registry .t file | [hold] | When registry-cvt generates .t file content in post .fp.xml form, deos653cvt needs to use that data. It will enable the test suite to pass. | 8 |
Tasks For registry-cvt
| Task | Assignee | Notes | Current Estimate |
|---|---|---|---|
| [0] Update regression test suite to model deos653cvt test suite. Also correct trace tags and update tracing to test cases | GK Done | 8 | |
| [1] Add requirements/tests for post Elbert kernel features. | TBR InWork | The PCRs against registry-cvt contain the information. In many cases, the kernel source code has pre-assigned the TQD tags, and those must be honored. As new requirements are incorporated, keep the associated PCR up to date with commit comments like "add [TQD_DRC_xxx] as specified in comment #n". | 32 |
| [2] Database population | GK - done | As the registry data is parsed, it needs to be added into the database. In many cases, this activity will have to be supported by CVT metadata. It may also be the case that the required CVT metadata is not yet present in the registry (IT updates). | ?? |
| [3] Reverse automation | Disintegration.doc as well as pi source code identify automatition steps that need be reversed (eg., remove idle process, transform numeric to symbolic values, pipc relate memory objects/quotas, VAS bonuses) | ?? | |
| [4] FP Magic | Extract compressed FP content into database. "Reverse run" the actions. | ?? | |
| [5] Post-FP .t file | This is trivial, but update the .t file to include post-fp/post-automation values. The source of data will be the database. The required amount of data to produce is the amount needed by the 653 cvt. | ?? | |
| [6] DO-178C | ML | TQD updates, trace matrix generation, | ?? |
| [7] Doc review | Someone should read the UG, TQD, and release notes to ensure everything is in order | 8 |
Components
Below are the Deos components being worked for this release. See also the list of FTP server symbolic links.
| Component | Version | Phase | CCB | Who | Remarks |
|---|---|---|---|---|---|
| deos-integration-tool | 3.8.0 | Dev | No | GK | Test Report |
| registry-cvt | 1.0.0 | Dev | No | GK/TR | |
| ioi-config | 3.4.4 | Stable | Yes | GK | Test Report |
| ioi-cvt | 1.5.5 | Dev | No | Test Report | |
| deos653config | 1.10.0 | Stable | Yes | GK | Test Report |
| deos653cvt | 1.2.0 | Dev | No | GK/TR | Test Report |
Legend
CCB: A Release CCB has been held
Phases:
- Dev - In Development
- Test - Component unreleased and ready to test
- Stable - You are done! All steps (including test report) in the Deos Software Release HowTo or OpenArbor Development HowTo have been followed.
Who: The person responsible for doing the work associated with the component.
Remarks: Free form text. It must contain the test report when done.
