@gedare @opticron
I am interested in the Port LittleFs project (issue #5354).
First are there any mentors assigned to the project? And I want to know if there are any documentation on how to properly port an existing software to RTEMS.
Also I need your guidance on how to approach the problem now, so i can understand the full scope. It will help me to create a proper timeline for the project in the proposal.
Thank you for your guidance.
We had a project that ported FatFS to RTEMS last year. You can check that out to see what kind of effort was involved there, see tracking/2025/Sepehr_Ganji.md · main · RTEMS / Programs / Google Summer of Code · GitLab
You could also try to contact the student who did that work and see if he might have any insight for you.
This is also related: Filesystem Implementation documentation outdated
Thank you I will look into everything you mentioned.
@gedare i am going through the documentations and references you sent.
I also sent MRs on the issues related to libfs and libblock, so I am also quite learning about the filesystems in rtems.
So, I just need a guidance should I start woking on the issue now, my first step would be to go through the LittleFs documentations and source code.
Yes, a successful proposal needs to have a solid understanding about the code being ported to know what dependencies it has, what kind of limitations might exist, how active the upstream is maintained or changes, and more.
I’ve completed my study of the RTEMS filesystem/VFS integration and documented my understanding. I’m ready to move on to analyzing littlefs and its integration points.
Great. It would be good to be able to show that you can run LittleFS on some target (e.g., baremetal or another RTOS), and to be able to describe how to debug it.
I ran LittleFS standalone using a file to simulate flash memory and I know how to debug basic issues.
@gedare Over the past few days, I’ve been studying both littlefs architecture (block abstraction, mount/format flow, crash-consistency model) and the RTEMS VFS integration model.
Based on that, I drafted a short integration approach. My current understanding is:
lfs_t in mt_entry->fs_info (one instance per mount)read/prog/erase/sync callbacks in a thin RTEMS glue layeropen_h, read_h, write_h, etc.) to the corresponding littlefs APIslfs_file_tBefore moving toward implementation experiments,I wanted to confirm whether this architectural direction aligns with expectations for the project.
This direction sounds reasonable to me. I believe you have enough that you will be able to start drafting your proposal.
Thank you for the confirmation. I’ll begin drafting the proposal.
I appreciate your guidance.
I noticed that a merge request has been opened related to the littlefs integration project. Since I am preparing a GSoC proposal for this project, I wanted to ask whether the task is still available for GSoC work or if I should consider focusing on another project instead.
I have already been studying littlefs and the RTEMS VFS integration points while drafting my proposal, so I wanted to confirm the current status before proceeding further.
The project is still available. That MR lacks engagement from the contributor, so I don’t know what its status is.
MR:
I did pushed the necessary changes described in the opened threads, I’m waiting for someone to review them. Please let me know if any other engagement you expect from my side.
I asked how you tested it.
Sorry I might have clicked “Add to Review” instead of “Add comment” while replying to all threads. That explains why I’m not getting any responses
update: I’ve added testcases to littlefs port (and all of them passes).
I wonder if its rude to ask, but can you tell me if there is any further actions I have to take for MR to be merged.
i think just some patience with the process as we are overloaded at the moment with GSoC and other activities.