CFFS Project/CFFS Multicore

From DDCIDeos
Jump to navigationJump to search

CFFS Support for multicore.

Overview

The original CFFS while thread safe, was not designed to be multi-core compatible. The User API to Server interface, and the Server to MAL interface uses memory mapped resources that if not fenced or cache managed properly could cause corrupted communication between the components.

Discussion

It is not unreasonable to expect the Server and MAL threads to be hosted on the same core, and the cffss32emmc MAL UG states this as an integration requirement. It is not practical however, to expect all CFFS users to be on the same core.

If all user threads were on the same core, the previously verified CFFS could be used. We haven't verified an ARM version yet, but that would just require a run for score with already developed code and tests on ARM hardware, with a single core limitation. This is a potential time saver for Harrys, a single core program.

Current Stable updates since the last verification added fences to the API interface, and left some TBDs behind that still need resolution. [PCR 10607] and [PCR 10734]

653P2 Features

  • The CFFS_A653P2 project documents limitations, some of which could be removed if new features were added to the CFFS Server/API, like directory support. Directory support is not a simple task as most file systems allow unlimited nesting, and the CFFS metadata was not designed, or intended to allow for directories. [PCR 9481]


  • Desert Eagle has a requirement for longer filenames, needing CFFS metadata updates.

Upgrades

  • CFFS to MAL interface allowing multiple DMA transactions per interrupt for controllers that allow table driven transfers to improve journal performance.
  • Journal redesign to allow more write transactions before a replay is required.
  • Journal of user data to prevent file corruption during unaligned and/or mid-file writes.
  • Directories
  • Longer Filenames

Other Options

  • HCC/Datalight Drivers
  • HCC/Datalight File Systems