We are finally here, at the midterm milestone! I’ve learned a lot and coded a bunch, made the porting of FatFS into RTEMS possible. This was a fantastic journey so far and I’m excited that there’s more of it.

Summary (so far)

Stage 1 started with me getting to know the fs concepts, including but not limited to what is being used in RTEMS. I dug into the dosfs code to understand how a similar fs would work. While doing that, I encountered 3 key concepts/modules:

1. handlers: These are the core part of any filesystem. They handler different functionalities like mount, read, write, etc. Every filesystem in RTEMS needs to implement it’s own handlers and store them somewhere in the mount table. This way RTEMS has a unified way of talking to filesystems regardless of their internal implementation. The good news is RTEMS provides some default implementation of those handlers, so we don’t have to actually implement all of them. I chose the “implement as you go” model where I used all the default ones, and then whenever I saw a need for my own handler, just did it.
2. libblock: This is where RTEMS talks to the hardware (like SD-Cards). There is a bunch of caching/buffering in place to optimize the whole process. I’ve put my filesystem on top of this code, and let it handle the actual talk to underlying hardware.
3. libio: This is the upper level in the code chain, that provides POSIX-like interfaces for I/O operations. This allows the users (developers) to use filesystem easily. We must make sure our code integrates this library and supports the POSIX-like system calls.

Image source: FatFS – Generic FAT Filesystem Module

You can see the general design of how FatFS will sit in any system. In our case, the yellow layer is libio, and the green layer is libblock.

After figuring these details, I went to actually get my hands dirty and code. The first step was to have the FatFS code inside RTEMS. After some debate on how to do it, we finally agreed on something and the MR is merged.

I have my own fork of RTMES here, where I do all of my development. The first (and the most crucial) step was to register FatFS as a filesystem in RTEMS and mount it. This includes putting the right things at the right files, making sure the code compiles, and testing the functionality. I’ve learned a ton of manual gdb debugging as I went along the way. After (almost) two weaks, the mount was working! My main source for test was the fileio test in the sample testsuites, and this link as my guide. We’ve already achieved the midterm milestone, but my not my ambitions, so I went ahead and wrote some testsuites to test the mount functionality.

I also implemented a lot of handlers for my filesystem to work. The fileio test is now (almost) functional! I can write to my filesystem and read from it. (It happened after a ton of debugging again 🙂 ).

I have huge changes to the codebase, not sure when is a good time to open an MR, but it should be about now. This is a matter to discuss with my mentor(s). There are still some issues with the fileio test, the listing of directory is not fully functional. I have to revisit what’s going on there and how am I handling the nodes and directory structures. I am already getting ahead of myself, so let’s go to the next section which is about Future Plans.

Future Plans

As I mentioned before, the fileio has some obvious bugs in directory navigation. So that would be the first thing on my plate:

• Fix directory navigation
• Merge current code into RTEMS (probably needs multiple MRs)
• Test: Now that I have most of the handlers, it’s time to look at testsuites for filesystem, and implement my own tests to make sure every aspect of my handlers work! This includes two steps:
  • Basic functionality (mount, unmount, open, close, read, write, seek, etc.)
  • Advanced functionality (link, unlink, permission, etc)
• Final touch: This is a time to take a step back and look at what I’ve done throughout the project. By carefully reading the FatFS code and docs again, I have to make sure I’ve considered every functionality and config possible. This integration is going to be part of RTEMS, so it must be robust!

My proposal originally contained benchmarking the filestystem as well. I’m not sure how much time would be left until the end of summer to cover that, but I’ll try my best to fit in some results to show this project was worth it! Maybe the full implementation of benchmarking stuff is a “post-GSoC” task to do.

That’s all on my side, I’m excited to start the second half of this project, now with more knowledge and a little bit more experience 🙂