{"id":75,"date":"2025-08-27T16:59:03","date_gmt":"2025-08-27T16:59:03","guid":{"rendered":"https:\/\/blog.ganji.dev\/?p=75"},"modified":"2025-11-11T14:50:44","modified_gmt":"2025-11-11T14:50:44","slug":"google-summer-of-code-2025-final-report","status":"publish","type":"post","link":"https:\/\/blog.ganji.dev\/?p=75","title":{"rendered":"Google Summer of Code 2025 &#8211; Final Report"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Project Goal<\/h2>\n\n\n\n<p>The goal was to <strong>replace DOSFS with a lighter FAT implementation and provide benchmarking<\/strong> \u2013 This was done by porting the open\u2011source <strong><a href=\"https:\/\/elm-chan.org\/fsw\/ff\">FatFS<\/a><\/strong> file\u2011system to RTEMS. This would offer a smaller, simpler alternative to RTEMS\u2019s custom DOSFS and reduce memory usage while maintaining functionality. The proposal also called for building integrated benchmarking tools to measure performance of different file\u2011system implementations.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Work Done<\/h2>\n\n\n\n<p>All of the code and tests I&#8217;ve wrote are available in this MR: <a href=\"https:\/\/gitlab.rtems.org\/rtems\/rtos\/rtems\/-\/merge_requests\/694\">https:\/\/gitlab.rtems.org\/rtems\/rtos\/rtems\/-\/merge_requests\/694<\/a><\/p>\n\n\n\n<p>Also, this is the epic with my progress report: <a href=\"https:\/\/gitlab.rtems.org\/groups\/rtems\/-\/epics\/25\">https:\/\/gitlab.rtems.org\/groups\/rtems\/-\/epics\/25<\/a><\/p>\n\n\n\n<p>Here&#8217;s a summary of what I accomplished during GSoC:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Integrating FatFS into RTEMS<\/strong> \u2013 I imported the upstream FatFS code into the RTEMS source tree and began implementing <code>diskio.c<\/code> to connect FatFS\u2019s disk I\/O layer to RTEMS\u2019s libblock.<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Mounting and basic file operations<\/strong> \u2013 By mid\u2011term, FatFS could be mounted and recognised as a valid file system. I created mount\/initialisation functions and taught <code>libio<\/code> to register FatFS volumes, allowing the existing <code>fileio<\/code> sample to mount FatFS instead of DOSFS. I&#8217;ve also implemented Disk I\/O handlers (<code>disk_initialize<\/code>, <code>disk_read<\/code>, <code>disk_ioctl<\/code> etc.).<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Expanding coverage to directory and file operations<\/strong> \u2013 I&#8217;ve added numerous handlers to make FatFS compatible with RTEMS\u2019s file, directory and path evaluation operations. I&#8217;ve also wrote\/adapted tests; fixed issues such as <code>ls<\/code> returning garbage characters or failing to handle trailing slashes.<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>POSIX\u2011compliance and bug\u2011fixing<\/strong> \u2013 Over the final weeks, I systematically ran RTEMS\u2019s filesystem test suite against the FatFS integration and fixed issues uncovered. Key fixes included handling <code>O_TRUNC<\/code> properly, updating file\/parent directory timestamps on writes and truncations, implementing <code>utime()<\/code> and <code>statvfs()<\/code>, mapping FatFS error codes to correct POSIX <code>errno<\/code> values, enabling large\u2011volume formatting (<code>FM_ANY<\/code> vs <code>FM_FAT<\/code>), and addressing lseek overflow semantics.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Future work<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Benchmark integration and performance evaluation<\/strong> \u2013 The project proposal included extending previous benchmarking tools for filesystem comparison. It would be a good next step to do this, and have a comparison between FatFS and other filesystems (specially DOSFS), from performance and memory footprint perspective. <\/li>\n\n\n\n<li><strong>[Done] Code review and upstream merge<\/strong> \u2013 After some final touches, we need to open MR, get reviews, and merge the code into RTEMS for the users to actually use this new filesystem \ud83d\ude42<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Challenges &amp; Lessons Learned<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Understanding RTEMS filesystem internals<\/strong> \u2013 Porting FatFS required mapping RTEMS\u2019s filesystem operations to FatFS primitives.  I learned about <code>libblock<\/code>, <code>libio<\/code> and <code>rtems_filesystem_operations_table<\/code> and how to integrate a new filesystem into RTEMS.<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Aligning FatFS behaviour with POSIX expectations<\/strong> \u2013 FatFS is designed for embedded systems and differs from POSIX in areas like timestamp handling and <code>fsync<\/code> semantics. I had to implement wrapper code to align with POSIX requirements and RTEMS conventions (e.g., <code>fsync<\/code> being called automatically at <code>f_close<\/code>).<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Debugging complex bugs<\/strong> \u2013 Issues such as double\u2011free corruption, inconsistent directory semantics, incorrect error code mappings, lseek overflow behaviour and large\u2011volume formatting required detailed debugging and test\u2011driven development. I learned a lot during hunting them down and fixing them!<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Final Thoughts<\/h2>\n\n\n\n<p>I\u2019m grateful to the RTEMS community for their support throughout this project, especially my mentors Chris and Gedare for their guidance, and Andrei for helping me get started with embedded systems. This has been a rewarding experience, and I\u2019ve enjoyed both the challenges and the chance to contribute to the community.<\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Project Goal The goal was to replace DOSFS with a lighter FAT implementation and provide benchmarking \u2013 This was done by porting the open\u2011source FatFS file\u2011system to RTEMS. This would offer a smaller, simpler alternative to RTEMS\u2019s custom DOSFS and reduce memory usage while maintaining functionality. The proposal also called for building integrated benchmarking tools [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-75","post","type-post","status-publish","format-standard","hentry","category-gsoc"],"_links":{"self":[{"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=\/wp\/v2\/posts\/75","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=75"}],"version-history":[{"count":11,"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=\/wp\/v2\/posts\/75\/revisions"}],"predecessor-version":[{"id":88,"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=\/wp\/v2\/posts\/75\/revisions\/88"}],"wp:attachment":[{"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=75"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=75"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ganji.dev\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=75"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}