On Mon, Feb 17, 2025 at 06:41:32PM +0800, Gao Xiang wrote: > > > On 2025/2/14 14:41, Andreas Hindborg wrote: > > Hi All, > > > > On behalf of the Linux kernel Rust subsystem team, I would like to suggest a > > general plenary session focused on Rust. Based on audience interest we would > > discuss: > > > > - Status of rust adoption in each subsystem - what did we achieve since last > > LSF? > > - Insights from the maintainers of subsystems that have merged Rust - how was > > the experience? > > - A reflection on process - does the current approach work or should we change > > something? > > - General Q&A > > Last year Yiyang worked on an experimental Rust EROFS codebase and > ran into some policy issue (c+rust integration), although Rust > adaption is not the top priority stuff in our entire TODO list but > we'd like to see it could finally get into shape and landed as an > alternative part to replace some C code (maybe finally the whole > part) if anyone really would like to try to switch to the new one. > > Hopefully some progress could be made this year (by Yiyang), but > unfortunately I have no more budget to travel this year, yet > that is basically the current status anyway. > > Thanks, > Gao Xiang > > > > > Please note that unfortunately I will be the only representative from the Rust > > subsystem team on site this year. > > > > Best regards, > > Andreas Hindborg > > > Since i'm cued in, I'd like to share some of my thoughts on the Rust. I've worked on the EROFS Rust codebase so far. I may have insights on the current status of Rust subsystem progress. On the Filesystem level, there still left a lot of yet to be determined especially. Reimplementing the core functionality of a filesystem is already ok, though not from perfect, and certainly we need a better abstraction to model the filesystem correctly in rust language.A lot of helpers (MM, BDev, Network Application Layer for NFS, etc.) are still left in the wild to be completed and it requires a lot of coordination from other subsystem maintainer and rust maintainer to abstract the C-API into Rust code a way that all parties can hold on to. I guess it's not the right time to do so in general, we can use rust in some specific filesystems but generally before other subsystems's API are stabilized, it's not a good idea to refactor the whole VFS codebase and abstract the API into Rust one. Filesystem should be free from memory corruption and rust is definitely worth the efforts to refactor some of the codebase. That means that we may need restrict the flexibility or somehow refactor the object model that current VFS uses and this certainly requires the original team that implements the VFS to be involved, at least express some willingness and interest to refactor instead of gatekeeping the whole codebase and shutting down the whole discussion (i don't mean to make criticism here BTW since we should be pretty cautionous on the original code and don't introduce certain regression issues.) But i guess the whole community is somehow polarized on this issue, it may not be an easy job to begin with, alas. Best Regards, Yiyang
