Re: The Case for Rust (in any system)

Hey Kristof

On Sun, Sep 8, 2024 at 1:44 AM Kristof Provost <kp@freebsd.org> wrote:

> On 6 Sep 2024, at 9:41, David Chisnall wrote:
>
> The strategy document that I coauthored at Microsoft recommended the
> following:
>
> - C++ conforming to the Core Guidelines and with static analysis for
> existing C/C++ projects with the C parts incrementally migrated to C++.
>
> While I’d be interested in seeing Rust demonstrated there are clearly
> still some practical issues to work out before we can, even in user space.
>
> So, at the risk of derailing the Rust conversation, I want to ask about
> C++.
>
> We already ship user space C++ code, what’s stopping us from doing so for
> kernel code?
> If we can get some of the benefit of a more modern language with much less
> effort would that be a worthwhile step? RAII would not *always* make
> reasoning about locks easier, but it would in at least 95% of cases.
>
> What would we need to do to be able to use C++ in the kernel?
>

So there's four big issues with C++ in the kernel, all surmountable if we
wanted.

There's the low-level allocation issues. Right now we know what memory is
used by what because we have malloc enhanced to track this (oversimplifying
a lot I know). So we'd need some framework to make it easy to have 'custom
allocators' that could track it as well. At a bare minimum, we need the
runtime support for new and delete...

Next, there's all the other run-time support that's provided by compiler-rt.

Next, there's the issues of exceptions. They are quite useful for RAII
(since you know dtors will get run when an error happens), and there'd need
to be some sane plan for these (or we'd have to forego them).

Finally, there's getting the subset of the standard library that's useful
into the kernel. There's a lot of templates for facilitating RAII that are
needed, for example, and some subset of STL, etc.

Once you have those 'table stakes' issues out of the way, you'll need to
see how it performs, and work out a few dozen logistical issues surrounding
what compiler flags to use, what language features to enable/disable, how
to optimize and what set of warnings are sensible.

You could start using C++ with just the second of these items.

Warner