[LSF/MM/BPF TOPIC] Rust in FS, Storage, MM

[LSF/MM/BPF TOPIC] Rust in FS, Storage, MM

[Andreas Hindborg]

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

Please note that unfortunately I will be the only representative from the Rust
subsystem team on site this year.

Best regards,
Andreas Hindborg

Re: [LSF/MM/BPF TOPIC] Rust in FS, Storage, MM

[Steve French]

sounds like a good idea.

I would love to have some experimental helper drivers in Rust for
cifs.ko and/or ksmbd
(e.g. fs/smb/common module for improved compression support over
SMB3.1.1, or SMB3.1.1 over QUIC, or for optional protocol features
that could be segmented into a common module shared by client and
server in fs/smb/common)

On Fri, Feb 14, 2025 at 12:41 AM Andreas Hindborg <a.hindborg@kernel.org> 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
>
> Please note that unfortunately I will be the only representative from the Rust
> subsystem team on site this year.
>
> Best regards,
> Andreas Hindborg
>
>


-- 
Thanks,

Steve

Re: [LSF/MM/BPF TOPIC] Rust in FS, Storage, MM

[Gao Xiang]

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
> 

Re: [LSF/MM/BPF TOPIC] Rust in FS, Storage, MM

[Yiyang Wu]

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