LKML Archive on
 help / color / Atom feed
From: Josh Triplett <>
To: (Eric W. Biederman)
Cc: Nick Desaulniers <>,,,, Masahiro Yamada <>,
	Linus Torvalds <>,
	Greg KH <>,
	Miguel Ojeda <>,
	Steven Rostedt <>,
	LKML <>,
	clang-built-linux <>
Subject: Re: Linux kernel in-tree Rust support
Date: Mon, 13 Jul 2020 14:33:26 -0700
Message-ID: <20200713213326.GA16462@localhost> (raw)
In-Reply-To: <>

On Mon, Jul 13, 2020 at 01:11:13PM -0500, Eric W. Biederman wrote:
> Nick Desaulniers <> writes:
> > Hello folks,
> > I'm working on putting together an LLVM "Micro Conference" for the
> > upcoming Linux Plumbers Conf
> > (  It's not
> > solidified yet, but I would really like to run a session on support
> > for Rust "in tree."  I suspect we could cover technical aspects of
> > what that might look like (I have a prototype of that, was trivial to
> > wire up KBuild support), but also a larger question of "should we do
> > this?" or "how might we place limits on where this can be used?"
> >
> > Question to folks explicitly in To:, are you planning on attending plumbers?
> >
> > If so, would this be an interesting topic that you'd participate in?
> I have two big concerns about actually using rust.
> 1) How large is the rust language support, and will each rust module
>    need to duplicate it.  I seem to remember someone mentioning it is
>    noticable in size.

There should only be a single copy, which could either be in the kernel
(if there's Rust code compiled into the kernel) or be in a "rust.ko"
support module. As long as you use the same version of Rust for the
kernel and all modules, you can supply symbols dynamically.

There are a few other steps we can take to control code size, as well.
In particular, there are tradeoffs between performance and size, such as
the amount of code in generics vs non-generics. (We also need to get
some further optimizations into Rust on that front, such as tail

As for the size overall, given that we'll just be providing the portions
of "core" and "alloc" that the built code actually uses, and likely not
providing "std" at all, I would expect the size to remain relatively

I very much care about overall kernel size, and I'm happy to help make
sure it remains reasonable.

> 2) What is rust usable for?  The rust type system will not admit
>    doubly linked lists (or anything where two pointers point at the
>    same memory) unless you are using an unsafe block.

There are libraries like intrusive-collections which implement
kernel-style structures with potentially multiple nodes in the structure
that put them into multiple lists at once. I would expect us to use
those (or in some cases implement our own). They don't need to be
written in C, just unsafe Rust that's wrapped up in a safe interface.

Just as the kernel has a variety of higher-level interfaces and data
structures that make working in the kernel sometimes *easier* than the
average C program, I'd expect that we'll end up with common Rust
structures that do what people need, rather than people reimplementing
their own.

- Josh Triplett

      reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 18:41 Nick Desaulniers
2020-07-09 20:52 ` Miguel Ojeda
2020-07-10  5:36 ` Josh Triplett
2020-07-10  6:28 ` Greg KH
2020-07-10 12:50   ` Christian Brauner
2020-07-10 16:10     ` Kees Cook
     [not found]       ` <>
2020-07-10 23:05         ` Kees Cook
2020-07-10 22:59     ` Josh Triplett
2020-07-10 23:54       ` Linus Torvalds
2020-07-11 21:03         ` Josh Triplett
2020-07-28 20:40           ` Pavel Machek
2020-07-29  6:34             ` Josh Triplett
2020-07-11 17:13 ` Geoffrey Thomas
2020-07-12 12:31 ` Adrian Bunk
2020-07-12 19:39   ` Josh Triplett
2020-07-12 20:33     ` Linus Torvalds
2020-07-12 20:45     ` Adrian Bunk
2020-07-14  8:27       ` David Laight
2020-07-16 13:06     ` Arnd Bergmann
2020-07-16 23:12       ` Josh Triplett
2020-07-19 18:19       ` Adrian Bunk
2020-07-20 14:46         ` David Laight
2020-08-23 21:02     ` Adrian Bunk
2020-08-23 21:54       ` Geoffrey Thomas
2020-07-13 18:11 ` Eric W. Biederman
2020-07-13 21:33   ` Josh Triplett [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200713213326.GA16462@localhost \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git
	git clone --mirror lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone