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.
Issue: Port STORfs (#5427) · Issues · RTEMS / RTOS / RTEMS · GitLab
Great! 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:
- Integrate directly in tree through
contrib? - Integrate through a build recipe in RSB?
I was able to build it on my linux machine. Afterwards I was able to run a sample program which basically performs all the operations you’d normally do but on a static memory region. The sample program came with STORfs itself and was present inside the Examples/test directory.
I also found a few very minute build warnings/errors which I went ahead and created PRs for on upstream. 
I will start looking into how other file systems are ported to rtems, I saw that FatFS was ported to rtems last year. That would be a good starting point.
Good, making contributions to the upstream is an excellent first step.
You’ll want to document and show your capabilities to work with the software as part of your proposal.
And yes, looking at other fs ports will be a good way to start your research. You’ll need to choose a BSP to work with. You should prefer one that has good support already to run filesystems with block device. It’s possible you can use a simulated environment.
I have been reading 1. Preface — RTEMS Filesystem Design Guide 7.1023b8c (8th January 2026) documentation and its sub chapters. And I can see that of lot of content is missing or have not been completed yet. I want to make sure that these aren’t deprecated and are still valid. If so, I might as well work on these while I am at it to improve the documentation for everyone.
I have also been working on STORfs upstream, merged a few patches, and currently studying how it works internally. Should I document these in my proposal as a proof of my capability to work with STORfs like you said?
And for choosing a BSP, I am planning to test it on atleast one 32bit and one 64bit architecture boards. Currently I am thinking of arm/xilinx_zynq_a9_qemu and aarch64/zynqmp_qemu_ilp32, both being arm is not a coincidence but rather a deliberate choice as I am most familiar with it. Will they suffice?
That manual may be a bit outdated and can certainly use some improvement. Definitely refer to previous GSoC contributor blogs and the rtems.git code, and ask questions.
You should definitely document the knowledge you’re building and work you’re doing as part of your proposal.
You might want to use the pc386 BSP for a 32-bit target. It has historically been easier for testing filesystem projects. However, the two you’ve chosen should be fine too.
I created a small MR which fixes some small typos and formatting issues with the filesystem documentation. I plan to create more MRs as I go along understanding filesystem in RTEMS.
I have been reading the filesystem code in RTEMS and the MRs and blogs created by @Sepehr for FatFS last year. Oh, and Sepehr sorry to ping you out of nowhere but I wanted to say your blogs and the comments on RTEMS gitlab has been really helpful so far, thank you for that . I plan to create similar blogs and documentation for future contributors
I noticed this issue libio needs to check the path length of any component is less than NAME_MAX (#5257) · Issues · RTEMS / RTOS / RTEMS · GitLab, and am trying to undestand and resolve it.
As I mentioned in the comment itself, I am confused as to where does exactly libio call filesystem operation handlers, the only place I could find was in libcsupport files like open.c, chmod.c etc. Is this the glue between RTEMS filesystem (operations table, locking-unlocking) AND abstracted away filesystem calls which doesnt need to worry about any of that?
@kiwichris I apologise for reaching out to you out of the blue, but I noticed you listed as a possible mentor for this project. And in the gsoc guidelines, it was stated that we should ask for feedback on our proposals from potential mentors as early as possible. I was wondering if you could take a look at the proposal I have created so far and provide some valuable early feedback?
Thank you!
PS: I can dm you the proposal here or on discord, whichever works best for you
you should send an MR to add your proposal to your tracking page.
done! heres the MR tracking/2026: Add project details for prashant rahul (!204) · Merge requests · RTEMS / Programs / Google Summer of Code · GitLab
@kiwichris Sorry to ping you again, would you mind looking at the proposal if you get time? Thank you!!
Here’s a direct link to the proposal GSOC2026_Rahul_Port STORfs to RTEMS - Google Docs