On Mon, Jan 22, 2024 at 11:23:51PM -0500, Kent Overstreet wrote: > There's been ongoing work on safe Rust interfaces to the VFS, as well as > whole new filesystems in Rust (tarfs, puzzlefs), and talk of adding Rust > code for existing filesystems (bcachefs, any day now, I swear). I really want this to happen. It's taken 50 years, but we finally have a programming language that can replace C for writing kernels. > Possible subtopics: > - Braces, brackets and arrow signs: does Rust have enough of them, too > many, or both? Um. Maybe we should limit ourselves to productive discussions that will affect the MM/filesystems/storage/bpf subsystems? While it's entertaining to read about Rust-as-it-might-have-been https://graydon2.dreamwidth.org/307291.html I quickly get lost in trying to learn the last three decades of language design to understand all the points being made. > - Obeying the borrow checker: C programmers are widely renouned for > creative idiosyncrasies in pointer based data structures; structure > design; will we be able to fully express our creativity within Rust? > Or are there VFS abstractions and lifetime rules that will be > difficult to translate? > > - Perhaps there are annoying VFS rules that in the past required hand > tattoos to remember, but we'll now be able to teach the compiler to > remember for us? > > (idmapping comes to mind as one area where we've recently been able > to increase safety through effective use of the type system - this is > about way more than just use-after-free bugs) > > - Moving objects around in memory: Rust rather dislikes being told > objects can't be moved around (a consequence of algebraic data > types), and this has been a source of no small amount of frustration > on the Rust side of things. Could we on the C side perhaps find ways > to relax their constraints? (object pinning, versus e.g. perhaps > making it possible to move a list head around) Death To List Heads! They're the perfect data structure for a 1995 era CPU. They leave 90% of your CPUs performance on the table if you bought your CPU in the last five years. If list heads make rust sad, then that's just one more reason to abolish them. > - The use of outside library code: Historically, C code was either > written for userspace or the kernel, and not both. But that's not > particularly true in Rust land (and getting to be less true even in C > land); should we consider some sort of structure or (cough) package > management? Is it time to move beyond ye olde cut-and-paste? Rust has a package manager. I don't think we need kCargo. I'm not deep enough in the weeds on this to make sensible suggestions, but if a package (eg a crypto suite or compression library) doesn't depend on anything ridiculous then what's the harm in just pulling it in? > The Rust-for-Linux people have been great - let's see if we can get them > to join us in Utah this year, I think they'll have things to teach us. It's definitely a two-way conversation. There's too much for any one person to know, so teaching each other what "we" need "them" to know is a great thing. I hear some people are considering pitching sessions like "What filesystem people get wrong about MM", "The pagecache doesn't work the way you think it does" and "Why directio and the pagecache are mortal enemies". And I'm in favour of those kinds of sessions (as long as I don't end up leading five sessions again ...).
