On Fri, Jun 09, 2023 at 11:22:12AM +0000, Ariel Miculas (amiculas) wrote: > Hello Christian, > > I didn't send these patches to a wider audience because this is an > initial prototype of the PuzzleFS driver, and it has a few > prerequisites before it could be even considered for merging. First of > all, the rust filesystem abstractions and their dependencies need to > be upstreamed, then there needs to be a discussion regarding the Yes. > inclusion of third-party crates in the linux kernel. > > My plan was to send these patches to the rust-for-linux mailing list and then start a discussion with Miguel Ojeda regarding the upstreaming approach. > There are a lot of new files added in this patch series because I've included all the dependencies required so that my patches could be applied to the rust-next branch, but these dependencies will most likely need to be upstreamed separately. > > It was never my intention to avoid your reviews, should I also send > subsequent patches to linux-fsdevel, even if they're in the early > stages of development? Yeah, I think that would be great. Because the series you sent here touches on a lot of things in terms of infrastructure alone. That work could very well be rather interesting independent of PuzzleFS. We might just want to get enough infrastructure to start porting a tiny existing fs (binderfs or something similar small) to Rust to see how feasible this is and to wet our appetite for bigger changes such as accepting a new filesystem driver completely written in Rust. But aside from the infrastructure discussion: This is yet another filesystem for solving the container image problem in the kernel with the addition of yet another filesystem. We just went through this excercise with another filesystem. So I'd expect some reluctance here. Tbh, the container world keeps sending us filesystems at an alarming rate. That's two within a few months and that leaves a rather disorganized impression.
