I am creating this topic to inform everyone that I am interested in working on this and creating my proposal around it, as well as to open a discussion about the project.
The work by WM Thornton is great starting point. But architecturally its not aligned with EEFS as far as I know. the current design implements block based filesystem but our EEFS is slot based header driven EEEPROM system with fixed file slots. Our CRC handling is incomplete, Path handling is incomplete , EEEPROM realities like atomic header updates and erase before write are not handled. and our mount integration is incomplete. There would have been more issues which can be addressed but these are my concern for now.
we can start working on slot based EEPROM first. Also make EEPROM file headers as authorative source with CRC so we could have easy power failure recovery also we can introduce clean EEPROM access layer with callbacks and keep filesystem independent of POSIX file I/O
With any porting effot there are usually a few common considerations for planning the proposal.
Can you build the software at all?
Can you run the software on anything?
Can you build the software with RTEMS?
Can you run the software with RTEMS?
Answering these questions will help you to frame the proposal and to plan the work. Once you know how to do #1-4, then you can consider what is the best way to integrate the software with RTEMS. Here again there are a few choices:
Sorry from my end for the ambiguity.
By our I mean about the community effort for the same EEFS project.
I have noted the considerations for the porting task.
My plan is to first focus on the basics: getting the EEFS code to build and run, then build and run within RTEMS using a simulated or mock EEPROM backend. Once that baseline is established, I can evaluate the right integration path (in-tree vs RSB) and then address EEFS-specific architectural gaps like slot-based layout, CRC handling, and power-failure safety.
Regarding the integration I am still analysing which approach would be better for us.
I was open for any suggestions or ideas from the community regarding the same so our approach for the issue is clarified.
Most of our filesystems are directly integrated in the tree, but there are some external (proprietary) ones that do not get integrated. In this case, considering the upstream has not been very active, it does make sense to put it in the RTEMS tree directly, but it is still necessary for you to do some research to determine if that really is the best solution.
I’ve done that research and it makes the most sense to do a direct integration. Primarily, EEFS is released under the NOSA which is wholly incompatible with the BSD license RTEMS uses. Additionally, as you point out the NASA tree is very stale for what it publicly released. I’ve already integrated a framework to get EEFS to build natively but the code itself needs a LOT of work to properly implement. D3athSkulll has already reached out to me directly regarding this implementation and has asked for time to meet, I’ve just been AFK for the past couple days dealing with personal things.
After our discussion. I have started analysing how other file systems are implemented here and how NASA EEFS differs from them. Thats a good starting point for me. I have compared the specification code in eeprom doc and the code implemented by WM Thornton and found out few differences where the specification and our implementation differ.
For example in the specification we use constant MAX_FILES for the file allocation table whereas in our implementation we have kept the max_files as dynamic sized parameter which is one of the case.