ARINC 653p2 File System On CFFS

From DDCIDeos
Jump to navigationJump to search

Description

This project's reason for existence is to develop an ARINC 653 Part 2 compliant file system that takes advantage of our existing Certifiable Fast File System (CFFS) component.

The proposed implementation consists of a Deos shared library implementing the specification's majority of requirements. Envisioned are some changes to the baseline CFFS server and API portions to support this new shared library. Along with this we may need some host tooling to assist with transformations between ARINC 653 and CFFS compliant configuration files.

Status

This project is in the estimation phase, serving at this time to help quantify various Statements-Of-Work.

Estimates

653P2 File System

Feature Estimate (Man Hours)
OPEN_NEW_FILE 40
OPEN_FILE 40
CLOSE_FILE 40
READ_FILE 40
WRITE_FILE 40
SEEK_FILE 40
REMOVE_FILE 40
RENAME_FILE 40
GET_FILE_STATUS 40
GET_VOLUME_STATUS 40
RESIZE_FILE 40
SYNC_FILE 40
OPEN_DIRECTORY 40
CLOSE_DIRECTORY 40
READ_DIRECTORY 40
REWIND_DIRECTORY 40
MAKE_DIRECTORY 40
REMOVE_DIRECTORY 40

Total: 720

CFFS Changes

Feature Estimate (Man Hours)
Directories 160
runtime read-only media detection 40
Misc changes to support 653P2 queries, e.g. GET_VOLUME_STATUS 80
Misc changes to support additional 653P2 configuration options, e.g. MaxNumberOfOpenFiles 80

Total: 360

Tool Changes

Feature Estimate (Man Hours)
653P2 config to CFFS config translator 160

Total: 160

Totals

Total Estimate = (720 + 360 + 160) = 1240

With Verification = (3 * 1240) = 3720

With Fudge Factor = (2.7 * 3720) = 10044

Notes

  • Estimates do not include any MAL activities.
  • While it is likely some APIs will take less or more time than others, we've averaged all out to the same estimated effort. This is to account for inter-API efforts such as data structure discovery, code factoring, etc.
  • Despite the constraints implied by its name, this shared library could likely be used within a native Deos application.
  • Not all FILE_STATUS_TYPE fields can be supported as not all media types provide the required information, e.g. NB_OF_WRITE_ERRORS.
  • This API really hinders our ability to out innovate our competitors. To wit from the READ_FILE service: "initiate and complete copy of OUT_LENGTH bytes from file and position described by FILE_ID to memory starting at MESSAGE_ADDR." That's right. The specification demands one copy memory, - a time sucking operation. The current CFFS allows reading clients access to their data without needing to copy it first. Perhaps we could provide a companion READ_FILE_BUT_BETTER API alongside?
  • SYNC_FILE will likely be mapped to a journal flush.
Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=ARINC_653p2_File_System_On_CFFS&oldid=21535"