From: Kent Overstreet <kent.overstreet@linux.dev>
To: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
rust-for-linux@vger.kernel.org
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Alice Ryhl <aliceryhl@google.com>,
Wedson Almeida Filho <wedsonaf@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Kees Cook <keescook@chromium.org>,
Matthew Wilcox <willy@infradead.org>,
Gary Guo <gary@garyguo.net>, Dave Chinner <dchinner@redhat.com>,
David Howells <dhowells@redhat.com>,
Ariel Miculas <amiculas@cisco.com>,
Paul McKenney <paulmck@kernel.org>
Subject: [LSF/MM TOPIC] Rust
Date: Mon, 22 Jan 2024 23:23:51 -0500 [thread overview]
Message-ID: <wjtuw2m3ojn7m6gx2ozyqtvlsetzwxv5hdhg2hocal3gyou3ue@34e37oox4d5m> (raw)
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
next reply other threads:[~2024-01-23 4:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 4:23 Kent Overstreet [this message]
2024-01-23 19:09 ` [LSF/MM TOPIC] Rust Matthew Wilcox
2024-01-23 21:04 ` Boqun Feng
2024-01-24 14:26 ` James Bottomley
2024-01-24 15:43 ` Matthew Wilcox
2024-01-24 16:04 ` James Bottomley
2024-01-24 18:50 ` Kent Overstreet
2024-01-24 19:23 ` Morten Linderud
2024-01-24 19:43 ` James Bottomley
2024-01-24 19:57 ` Kent Overstreet
2024-01-25 3:47 ` James Bottomley
2024-01-25 9:24 ` Kent Overstreet
2024-01-25 21:30 ` James Bottomley
2024-01-23 22:58 ` David Howells
2024-01-24 3:57 ` Boqun Feng
2024-01-24 21:20 ` Kent Overstreet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=wjtuw2m3ojn7m6gx2ozyqtvlsetzwxv5hdhg2hocal3gyou3ue@34e37oox4d5m \
--to=kent.overstreet@linux.dev \
--cc=aliceryhl@google.com \
--cc=amiculas@cisco.com \
--cc=brauner@kernel.org \
--cc=dchinner@redhat.com \
--cc=dhowells@redhat.com \
--cc=gary@garyguo.net \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=paulmck@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wedsonaf@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).