FS - externalize cfe_fs_decompress

[skliper]

The decompression code should be removed and compile-time hooks to connect in an external decompression library should be provided.

[skliper]

Imported from trac issue 260. Created by cdknight on 2018-12-11T16:57:03, last modified: 2019-07-03T12:32:27

[skliper]

Trac comment by cdknight on 2018-12-11 16:58:45:

Much discussion on the mailing list early December 2018, initiated by a user finding a bug in the decompression code. My recommendation is as the ticket describes, externalize the code.

One suggestion is to use the "ExternalProject" capability in the latest CMake:

https://github.com/abseil/googletest/blob/master/googletest/README.md#incorporating-into-an-existing-cmake-project

[skliper]

Trac comment by jhageman on 2019-07-03 12:25:14:

From @acudmore:

LZMA compression SDK:
https://www.7-zip.org/sdk.html

We used this on MMS/RTEMS, and Dellingr/FreeRTOS for the elf loader we created. The development host tool optionally compresses the code and data segments, then the flight loader decompresses the segments.
On Dellingr, the original ACS static load file (.slf) was 103Kbytes. Using the lzma compression it was 19Kbytes. This was key for our ability to upload new apps on Dellingr.

The embedded decompress code consists of a single header and single C file. The license is public domain and should be compatible with Apache 2.0.

[skliper]

Trac comment by jhageman on 2019-07-03 12:32:27:

Or zlib or similar.

Preference from cFE would be to provide an interface where one or more of these open source solutions could be easily plugged in. I suggest not building anything in by default.

[skliper]

Externalization question @acudmore @CDKnightNASA @jphickey:

There is functionality that doesn't link to any requirements within ES, where an app file or library file that ends in ".gz" is uncompressed before loading that depends on this code. In context of externalizing decompress, what approach should we take? Do we take out this functionality in ES so that decompress can be moved to a standard cFS library (distributions could still 2-step loading apps that are compressed using FM to decompress and then ES to load, but the core set would need to be uncompressed)? Any other externalization approach I can think of just leads to more complexity, and/or configurations that will fail (adding an unimplemented "module" option will just fail, so it seems like the core needs to include at least one functional decompress if the unrequired capability needs to become fully supported), or dependency on non-flight libraries. Definitely open to suggestions.

[jphickey]

I think this is an area where the specific use cases of this feature need to be identified to figure out what is really the "right" way to do it.

This seems to be related to systems that have very limited storage space but ample RAM, as it trades persistent storage space to store the files for increased RAM usage at runtime (as it decompresses to a RAM disk).

I can say that the GRC deployments do not use or require this feature at all. I believe JSC in the past has said that they require it, however.