On Fri, Jun 9, 2023, at 7:45 AM, Christian Brauner wrote: > > 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. (Not a kernel developer, but this argument makes sense to me) > 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. I am sure you are aware there's not some "container world" monoculture, there are many organizations, people and companies here with some healthy co-opetition but also some duplication inherent from that. That said at a practical level, Ariel in the https://github.com/containers GH organization we're kind of a "big tent" place. A subset of the organization is very heavily Rust oriented now (certainly the parts I touch) and briefly skimming the puzzlefs code, there are definitely some bits of code we could consider sharing in userspace. Actually though since this isn't releated to the in-kernel discussion I'll file an issue on Github and we can discuss there. But there is definitely a subset of the discussion that Christian is referring to here that is about the intersections/overlap with the composefs approach that is relevant for this list. Maybe we could try to collaborate on an unbiased "puzzlefs vs composefs" document? (What's in https://github.com/anuvu/puzzlefs/tree/master/doc is a bit sparse right now)
