Dear OpenAFS Developers, I hope you're doing well!
I'm reaching out to express my genuine interest in contributing to the OpenAFS project, particularly around the topic of multi-page folio support in the OpenAFS Linux kernel module. I’ve been closely following developments in memory management and distributed file systems, and I’m excited about the opportunity to explore how OpenAFS can better leverage the folio API to improve efficiency. Before diving deeper into the work, I have a couple of questions to help guide my contributions: 1. Which areas of the OpenAFS codebase currently handle page-level operations that would benefit most from multi-page folio support? >From the description, it seems that the read/write and metadata paths are key candidates, but I would appreciate your insights on which areas might have the biggest impact in terms of performance or future maintainability. 2. How should I approach compatibility across kernel versions with differing levels of folio support? Is it better to use feature checks/macros for conditional support of multi-page folios, or is there a minimum kernel version we should target for full compatibility? Additionally, if there are any existing discussions, patches, or related resources (like LKML threads or kernel commits) that could provide more context on folio usage in OpenAFS, I’d be grateful for any pointers. I also wanted to mention that I’ve applied for the Google Summer of Code (GSoC) this year with the OpenAFS project. While I’m hopeful for that opportunity, I’m already eager to contribute in any capacity and am excited to learn from the community. Thank you for your time, and I look forward to any guidance or feedback you might have. I’m excited to be part of the OpenAFS project and contribute where I can! Best regards, Utkarsh Maurya projects.utkarshmau...@gmail.com GitHub: pro-utkarshM _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
