Add a dedicated page for Google Summer of Code 2026

src/gsoc.md

@@ -0,0 +1,180 @@
+# 🌞 Google Summer of Code 2026
+
+## About Google Summer of Code
+
+The [Google Summer of Code](https://summerofcode.withgoogle.com) is a global,
+online program focused on bringing new contributors into open source software
+development.  Contributors work with an open source organization on a 12+
+week-long program under the guidance of mentors.
+
+## Project Proposal Guidelines
+
+Contributors/applicants are responsible for writing a proposal and submitting
+it to Google before the application deadline.
+
+See the Project Ideas for a starting point for project ideas.  We welcome
+proposals which are variations of these project ideas and new project ideas
+as well. Please reach out to us on the development mailing list or Matrix
+room to discuss project proposals.
+
+In order to ensure the projects run healthily, your proposal must contain
+a clear yes/no statement about whether you used LLM-based AI tools (ChatGPT,
+Gemini, etc.) to help you write it. Include exactly one of the following
+statements in your proposal:
+
+`This proposal was written with the assistance of [ChatGPT/Gemini/etc] to [check spelling / check accuracy / format text].`
+
+or:
+
+`This proposal was written without the use of any AI tools.`
+
+If your proposal does not contain either of these statements, your proposal
+will not be considered.
+
+Using AI tools for refining project proposals is allowed, but please try to
+keep the proposal within your own development capability.
+
+Please **do not submit a proposal completely generated by AI** since it's
+just a waste of our time.
+
+## Project Ideas
+
+(multi_threaded_decompression)=
+
+### Multi-threaded Decompression Support in fsck.erofs
+
+Proposed mentors: Yifan Zhao ([@SToPire](https://github.com/SToPire)), Chunhai Guo ([@speedan1](https://github.com/speedan1)), Gao Xiang ([@hsiangkao](https://github.com/hsiangkao))  
+Languages: C  
+Estimated project length: 350 hours  
+Difficulty: hard  
+Skills:  
+ - Proficiency in C programming;
+ - Experience with multi-threaded programming;
+ - Experience with file system concepts and operations.
+
+**Description**
+
+EROFS is designed for modern high-performance immutable use cases and is
+widely used in OS images such as Android system images and container images.
+Its userspace tool, fsck.erofs, is critical for filesystem integrity checking,
+image unpacking, and regression testing.
+
+Currently fsck.erofs is strictly single-threaded, therefore it unpacks each
+file one-by-one, even though:
+
+ - EROFS compression units (e.g., pclusters) are largely independent;
+ - Modern computer systems provide abundant CPU parallelism;
+ - Unpacking workloads for compressed files are often CPU-bound rather than
+   I/O-bound.
+
+For large images, extraction time scales poorly, which negatively impacts
+image installation, CI pipelines and/or developer workflows.  Therefore,
+introducing multi-threaded decompression would unlock significant
+performance improvements of these use cases.
+
+The primary goal is to design and implement a new multi-threaded
+decompression pipeline for fsck.erofs that is efficient, safe and
+maintainable.
+
+Specific goals:
+
+- Parallelized decompression at different levels (compressed clusters,
+  inodes, etc.)
+- Always perform better than the single-threaded approach among all
+  supported algorithms (LZ4, LZMA, DEFLATE and Zstandard);
+- Maintain correctness and stability;
+- Minimize memory overhead and contention;
+- The unpacking performance of metadata compressed filesystems should
+  be greatly improved too;
+- Add tests to look after this new feature (e.g. stress tests).
+
+### Support generating filesystems from manifests with mkfs.erofs
+
+Proposed mentors: Chengyu Zhu ([@ChengyuZhu6](https://github.com/ChengyuZhu6)), Gao Xiang  
+Languages: C  
+Estimated project length: 175 hours  
+Difficulty: medium  
+Skills:  
+ - Proficiency in C programming;
+ - Experience with file system concepts and operations.
+
+**Description**
+
+For local builds, currently mkfs.erofs only supports generating from source
+directories or tarballs. However, building from source directories has the
+following disadvantages:
+
+ - Limited inode metadata control;
+ - Requires privileges for special inodes;
+ - No explicit data dump ordering control;
+ - Slower for very large filesystem trees.
+
+The primary goal is to implement the functionality to generate EROFS images
+from manifest files.  Note that manifest formats are highly fragmented, so you
+should implement support for at least two common manifest formats, for example:
+
+ - [composefs-dump(5)](https://manpages.debian.org/testing/composefs/composefs-dump.5.en.html);
+
+ - Modified [unix proto files](https://www.ibm.com/docs/en/aix/7.3.0?topic=m-mkproto-command);
+
+ - BSD [mtree(5)](https://man.freebsd.org/cgi/man.cgi?query=mtree&sektion=5&format=html).
+
+Dedicated test cases should be added to ensure its correctness.
+
+### Complete filesystem feature support for erofs-rs
+
+Proposed mentors: [@Dreamacro](https://github.com/Dreamacro), Gao Xiang  
+Languages: Rust  
+Estimated project length: 350 hours  
+Difficulty: hard  
+Skills:  
+ - Proficiency in Rust programming;
+ - Experience with file system concepts and operations.
+
+**Description**
+
+*TBD*
+
+(porting-erofs-to-freebsd)=
+
+### Porting EROFS to BSD Kernels (FreeBSD Focus)
+
+Proposed mentors: Gao Xiang, Hongbo Li ([@hb-lee](https://github.com/hb-lee))  
+Languages: C  
+Estimated project length: 350 hours  
+Difficulty: medium  
+Skills:  
+ - Proficiency in C programming;
+ - Experience with file system concepts and operations.
+
+**Description**
+
+EROFS is a high-performance, space-efficient read-only filesystem widely
+used in the Linux ecosystem, particularly for immutable infrastructure,
+containers, and embedded systems.
+
+Today, EROFS is heavily used in:
+
+ - Android system images;
+ - Container images and snapshotters (containerd, gVisor, Kata containers);
+ - Immutable OS (AWS Bottlerocket) and cloud infrastructure.
+
+However, BSD kernels currently lack native implementation for EROFS, forcing
+interested users to rely on other alternatives. Porting EROFS to BSDs would:
+
+ - Enable direct mounting of native EROFS images;
+ - Improve interoperability between Linux and BSD systems;
+ - Provide FreeBSD with a modern high-performance immutable filesystem
+   optimized for container and immutable OS workloads.
+
+The primary goal is to implement EROFS filesystem support in the FreeBSD
+kernel, following FreeBSD VFS conventions while remaining compatible with
+the standard EROFS on-disk format.
+
+Key objectives:
+
+ - Implement a FreeBSD kernel EROFS filesystem driver;
+ - Support mounting and reading standard EROFS images;
+ - Integrate EROFS with FreeBSD’s VFS, buffer cache, and VM systems;
+ - Validate correctness and performance using real-world workloads;
+ - Lay groundwork for future BSD ports (OpenBSD, NetBSD).

src/index.md

@@ -174,6 +174,7 @@ casestudies.md
 design.md
 developers.md
 roadmap.md
+gsoc.md
 ```
 
 ```{toctree}

src/roadmap.md

@@ -1,6 +1,7 @@
 # 🗺 Roadmap
 
-Note that items marked with **\[SoC\]** are also intended for Summer of Code projects.
+Note that items marked with **\[GSoC\]** are also intended for Google Summer of
+Code (GSoC) projects.
 
 ## Linux Kernel
 
@@ -12,7 +13,7 @@ Note that items marked with **\[SoC\]** are also intended for Summer of Code pro
 
  - Stabilize liberofs APIs;
 
- - **\[SOC\]** [Multi-threaded decompression](https://github.com/erofs/erofs-utils/issues/33);
+ - **\[GSoC\]** [Multi-threaded decompression](gsoc.md#multi_threaded_decompression);
 
  - Fanotify on-demand loading support (using fanotify pre-content hooks);
 
@@ -28,4 +29,4 @@ Note that items marked with **\[SoC\]** are also intended for Summer of Code pro
 
 ## Miscellaneous items
 
- - **\[SOC\]** [Porting EROFS to BSD Kernels](https://github.com/erofs/freebsd-freebsd-src/issues/1).
+ - **\[GSoC\]** [Porting EROFS to BSD Kernels](gsoc.md#porting-erofs-to-freebsd).