DVMS A653p2 Move

This project's goal is to present and discuss the vfile-api653p2 and vfile-api653p2-examples components' move across all of our tooling.

What is the current status/problems?

See here for all of the PCRs in question: https://deos.ddci.com/ddcibugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Deos&component=vfile-api653p2&component=vfile-api653p2-examples&list_id=9907&product=ARINC653&query_format=advanced

Problems:

• The name: The vfile-api653p2 component has "vfile" in its name, but we are hoping to change this as it does not live inside of vfile. Do we want to name this component, "dvms..." or "deos..."?

1. on the ftpserver, the actual tar.bz2/release notes is "vfile...". Will this cause issues if we rename it to something else?
2. in private svn, it is "vfile..."
3. name in bugzilla as well

• The bugzilla location: The component is currently stored at Private Bugzilla | Deos | ARINC653, but we are aiming to move it under DVMS.

• The standard: There is a new standard: https://aviation-ia.sae-itc.com/standards/arinc653p2-4-653p2-4-avionics-application-software-standard-interface-part-2-extended-services

Features:

• The current port from CFFS presumes an underlying file system for both the P2 File System, and Logbook.

1. P2 File System:
   1. Should this iteration allow usage on RAW volumes absent a file system, returning error codes for unsupported features?
2. P2 Logbook System:
   1. Should this iteration allow usage on RAW volumes absent a file system?
   2. Should the design support an interface directly to "other" non-volatile memory (i.e. via a custom MAL), or will vfile handle that for "free" (i.e. raw volume on device other than say SATA, like battery backed RAM, EEProm, etc)?
3. Decisions here probably affect 653 config tool as well.