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). Maybe it's time to get together and see what sort of trolling^H^H^H^Hserious design discussions we can come up with? Possible subtopics: - Braces, brackets and arrow signs: does Rust have enough of them, too many, or both? - 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) - 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? - What's the development and debugging experience been like so far? Who's got stories to share? 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. Cheers, Kent
