
QEMU should move from C to Rust - rwmj
http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c-to-rust.html
======
spankalee
Is it worth the effort to write a "X should switch to Rust" post that ends
with "but I personally don't have the appetite to do it"?

Migrations of this size aren't not done because they're technically bad ideas,
but exactly because they're expensive, messy, and few people have the appetite
or funding to do it. Proposing a solution to that is more interesting that
just saying "switch to Rust!".

Also, I don't know much Rust (still on my PL bucket list), but usually when I
dive into a more detailed analysis of such a migration the most relevant parts
are around how much unsafe code will be required and whether or not
integrating with the existing codebase has to be fine-grained or can be done
in larger modules like Rust recommends.

I would naively guess that a VM would have lots of unsafe code. Are there any
investigations on whether the recent vulnerabilities would have migrated to
safe or unsafe code?

edit: mea culpa. I didn't read the second to last-paragraph closely enough,
which at least proposes a modularized way of doing this with device emulation
being written in Rust in separate modules.

~~~
slim

      Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"?
    

he made it to the front page of HN, so I guess the answer is "Yes"

~~~
nomel
Entertainment value is separate from practical value and feasibility.

~~~
adsjhdashkj
Maybe the practical value is traffic?

------
rectang
The blog post proposes an _incremental_ migration.

From the next to last section "How can we change programming language?":

> _The reason I am writing this post is because device emulation, the main
> security attack surface for VMMs, can be done in a separate program. That
> program can be written in any language and this is where Rust comes in. For
> vhost devices it is possible to write Rust device backends today and I hope
> this will become the default approach to writing new devices._

For all those criticizing the knee-jerk impulse to rewrite, you're arguing
against the wrong post!

~~~
xiphias2
It seems that the controversies in the comments come from the inexact title.
It should have been ,,Why QEMU should incrementally move from C to Rust'', or
something similar, that reflects the content of the article better.

~~~
roblabla
Or maybe people should read the post instead of reading too much into the
title?

~~~
afiori
but the title is important, it claims that the article will give sufficient
reasons for QEMU to stop using C in some natural sense and move to Rust.

if this is not the reflective of the content or it is a tongue in check
exaggeration following a c common template (similarly to the "considered
harmful" titles) it is reasonable to criticize the title

(it is less reasonable to criticize the article under the assumed content)

------
IceWreck
Whats with the treand of why X should move to Rust these days?

Not saying Rust is flavour of the week but this happens with a new language
every couple of years. Everything doesn't need to be rewritten. You switch
languages, you might fix some existing bugs but you open lots of other ones.

~~~
steveklabnik
This blog post discusses specifically what would be gained by moving to Rust,
and why Rust. The word "re-write" does not appear. It is actually suggesting
that new work be started in Rust. It even suggests that re-writing what's
there is a bad idea!

~~~
rectang
You'd never know that the blog post describes such an incremental strategy
from all the top-level posts on this page rushing to argue against the straw
man of a complete rewrite. :\

~~~
vlovich123
Like almost even those that claimed to read the article did so haphazardly.

------
ghostwriter
All bullet points under "Why Rust?" actually suggest that it would be much
better to gradually rewrite all critical parts of the project in ATS, thanks
to it being a frontend to GCC. Firstly, it's a much more powerful frontend
than the current Rust. Secondly, I'd expect it to be less disruptive than a
complete compiler switch.

~~~
jcranmer
From a cursory search, it looks like ATS is implemented as a "compile to C
code" language. This kind of implementation is actually quite concerning,
because it means you're punting through a language which is notorious for its
heavy reliance on undefined behavior, and there is no way to opt out of
undefined behavior in some cases.

Also, from what I can tell of its mailing list, ATS is a pretty dead project:
[https://sourceforge.net/p/ats-lang/mailman/ats-lang-
users/](https://sourceforge.net/p/ats-lang/mailman/ats-lang-users/) shows only
announcements post-2015.

~~~
lmkg
A language that compiles to C does not inherit all of C's problems, and
doesn't "punt" on it for undefined behavior. I mean, after all, Rust compiles
to Assembly, which is even unsafer than C, but Rust is still considered safe.

A compiler has greater ability to enforce invariants that make the resulting
code safe. The issues with C result from faulty humans; running through a
program gives an opportunity for those issues never to occur to begin with.

~~~
umanwizard
How is assembly less safe than C? C is full of undefined behavior which might
be interpreted differently by different compilers, whereas (maybe with the
exception of some unusual circumstances) the behavior of assembly language for
major instruction sets is 100% documented.

~~~
ncmncm
I see that you have not coded in assembly language.

~~~
umanwizard
I haven’t; I’ve only read it a bit. I could be wrong about a relative lack of
UB compared to C - do you have examples?

~~~
ncmncm
When you code in assembly language, you discover how incompletely documented
every chip is. Any detail of behavior not documented might change in a later
chip, and is thus UB.

Makers of compatible chips are obliged to keep a collection of systems with
all the extant chip designs to run experiments against, and to maintain their
own documentation of discovered but unspecified commonalities that users' code
may have come to depend on.

Each released chip, and each stepping of each release, has its own unique set
of bugs-- deviations from documentation, from observed behavior of previous
chips, and of chips yet to be released.

Writers of assembly code need a compendium of behaviors, documented or not,
that cannot be relied on for the set of release platforms. Many such bugs
depend on an ill-characterized history of processor states, making them,
often, (more or less) reliably reproducible only with a particular program
that was discovered to evoke each. Often the behavior noted is seen only once
in a million runs.

An example on Intel is the popcount instruction that runs very slowly,
sometimes, in chips released up to a few years ago. The instruction appeared
along with ...SSE3?, and had the bug until it was noticed and fixed in a
subsequent chip. The bug is the reason Gcc uses the same register for source
and destination when it emits this instruction. Intel's ISA manual does not
mention this behavior.

~~~
umanwizard
Thank you for the details. I guess I had an overly rose-tinted view of the
quality of Intel documentation.

------
vbezhenar
What’s the status of the Rust project after recent Mozilla layoffs? How much
does Rust depend on Mozilla?

~~~
tannhaeuser
The message in Mozilla laying off the Servo team, for me, isn't so much that
Rust is dying as it's about a team making their programming language a
priority can't at the same time focus on their actual task ie developing a
browser. What a missed opportunity to specify web layout in a constraint
formalism (and I hate to always be right).

~~~
wwwwwwwww
Evidently they can. The Servo parts are the only things that are fast in
Firefox.

~~~
tannhaeuser
The Servo parts in FF is a CSS "engine" right? My expectation is that at some
point it gets rewritten to C++ like the rest (layout, RT, API, fonts, parsing,
JS, UI) because having a minor part written in Rust (with an extra build
system, test framework, API bindings to maintain) is only a hindrance to
building a team able to pickup work of other members. Especially when that
other language has failed to deliver, and not even demonstrated the
feasibility to develop a competitive JS VM, nor fast-enough binding to eg
FreeType.

~~~
steveklabnik
Stylo, the component you're talking about, was written in Rust after multiple
attempts to write it in C++, which all failed. So, I would hope that that
isn't what happens. It sounds like a waste of time.

> having a minor part written in Rust

"every single CSS bit touches this code" isn't a minor part, and it's not the
only part. [https://4e6.github.io/firefox-lang-
stats/](https://4e6.github.io/firefox-lang-stats/) is a sorta flawed metric
but it reports nearly 10% being Rust.

------
dahfizz
The following justifications are given:

-Use-after-free, double-free, memory leaks, and other lifetime bugs are prevented at compile-time by the borrow checker where the compiler checks ownership of data.

-Buffer overflows and other memory corruptions are prevented by compile-time and runtime bounds-checking.

-Pointer deference bugs are prevented by the absense of NULL pointers and strict ownership rules.

-Uninitialized memory is prevented because all variables and fields must be initialized.

These are all only true in _safe_ rust. A hypervisor has to do low level
things like translate memory addresses, move stack pointers around, etc.
Nearly all the buggy C code, if implemented in Rust, would be wrapped in
'unsafe' and would be just as buggy.

I recommend everyone interested in Rust to take a look at how the standard
library Vec is implemented[1]. The code is littered with `unsafe` - There is
just no way to avoid it and do something useful at the same time.

This isn't really a shortcoming of the language, but of modern computers. It
is fundamentally an unsafe operation to read or write memory, to communicate
with a disk, etc. Every computer program is fundamentally unsafe. Rust does a
fantastic job of making this explicit and controlling it as much as possible,
but the idea that Rust code is bug free for free is just wrong.

[1] [https://doc.rust-
lang.org/src/alloc/vec.rs.html#300-303](https://doc.rust-
lang.org/src/alloc/vec.rs.html#300-303)

~~~
estebank
I think the Vec example makes the opposite argument from the one you put
forth. Vec uses unsafe internally in order to have the desiref API and
performance characteristics, but it exposes a safe API. If there are bugs in
the unsafe blocks that can cause UB all over the place, but it also makes it
easier to audit.

> There is just no way to avoid it and do something useful at the same time.

I don't think that's true. Your code might have to rely on code down the
abstraction layers that uses unsafe, as interacting with the hardware is
inhere you unsafe, but that doesn't mean that any code you want to write won't
be able to leverage the safe abstractions. The argument you're making sounds
to me, and please correct me if I'm misunderstanding, that trying to create
safe abstractions is sheer folly so we might as well not do so.

I've been writing Rust code for years now and I've never had to write unsafe
code myself other than when interacting with C code and when doing so I've
found issues with the way the API the C libraries were exposing having
fundamental issues.

~~~
dahfizz
> Your code might have to rely on code down the abstraction layers that uses
> unsafe, as interacting with the hardware is inhere you unsafe, but that
> doesn't mean that any code you want to write won't be able to leverage the
> safe abstractions.

This is the point I was trying to make by linking to the vec code. Any useful
Rust program _will_ run unsafe code. That code might just be hidden in a
library. Ultimately, you are trusting that the code author did not write any
bugs - in this regard you are not much safer than using the C++ stl.

> The argument you're making sounds to me, and please correct me if I'm
> misunderstanding, that trying to create safe abstractions is sheer folly so
> we might as well not do so.

On the contrary! I think what Rust is doing is a big step forward. But it is
very important to keep in mind the limitations of a system.

The authors attitude of "This is written in Rust, so it must be free of memory
bugs!" is dangerous. The key benefit of Rust is to isolate and explicate the
dangerous parts of your program (because there are dangerous parts!!). This
should make you _more_ vigilant of bugs, but the "Eh, the borrow checker will
debug for me" attitude can often lead to programmers being less critical of
their own code.

Of course, none of this really applies if you are doing higher level stuff.
But QEMU would definitely have to write their own 'unsafe' code.

~~~
tedmielczarek
Here's the thing these arguments always miss: writing C/C++ is like writing
your _entire_ Rust program using unsafe. Sure, unsafe Rust code will always
exist and can cause memory safety bugs. It's a lot easier to verify a few
unsafe blocks in a Rust program than it is to keep all of your C++ program's
invariants in your head and manually make sure you don't violate them.

------
nrclark
For the Rustaceans in the thread, I've been wondering - What's the current
state of affairs of Rust for non-x86_64 targets? I know it's in flux, and that
documentation isn't always up to date.

What architectures can rustc target? Can it cross-compile? Can I cross-compile
rustc itself, or do a Canadian-cross (where I cross-compile a rustc that wants
to target a different architecture than the one that hosts the compiler)?

Speaking as somebody who does a ton of system programming for embedded Linux
systems, this is basically C/C++'s biggest advantage over Rust - the extreme
flexibility of the available toolchains.

~~~
steveklabnik
Every Rust compiler is a cross compiler. There can be some issues on some
combinations of cross compiling, that is like, you can't run link.exe on a Mac
so cross compiling from a Mac to Windows only works if you don't use the msvc
target, stuff like that. I personally work on embedded ARM stuff on Windows,
so I'm cross compiling from x86_64-pc-windows-gnu to thumbv7em-none-eabihf all
the time. No need for a special build or setup, just a "rustup target add
thumbv7em-none-eabihf && cargo build --target=thumbv7em-none-eabihf" and
that's it.

ARM themselves are committing to getting the various ARM targets to Tier 1
support. AVR support landed in nightly recently. Other targets have less
support, but that's mostly due to lack of people power, not a lack of interest
from us.

~~~
Arnavion
I know you know this, but just to clarify for other people, "Every Rust
compiler is a cross compiler" is only true for pure Rust code. You'll still
need a C cross-compiler toolchain to link your final binary, and any Rust
libraries that are bindings to external libraries and expect those libraries'
C headers / link objects to be pre-installed [1] will need said external
libraries' C headers / link objects to be available for the target
architecture.

So the availability of a C cross-compiler toolchain can affect your ability to
compile Rust code for foreign architectures. As a concrete example, at $dayjob
we need to compile our code for CentOS 7 armv7 and aarch64, but CentOS 7 does
not have a usable cross-compiler toolchain in its repos [2], so we have to run
the build process in a centos7 arm container running under qemu.

[1]: Eg openssl-sys is bindings to openssl and expects you to have installed
the equivalent of your distro's openssl-devel package. In cross-compilation
scenarios, this means installing the openssl-devel package for the foreign
arch. For debian you'd do something like `dpkg --add-architecture armhf; apt
install libssl-dev:armhf`

[2]: What it has is only for cross-compiling the kernel, so there's no cross
glibc available to link the final binary to.

~~~
steveklabnik
Ah yes, thank you. I should make sure to clarify that better in the future :)

------
KindOne
Discussions on reddit:

[https://www.reddit.com/r/linux/comments/i56gzj/why_qemu_shou...](https://www.reddit.com/r/linux/comments/i56gzj/why_qemu_should_move_from_c_to_rust/)

[https://www.reddit.com/r/rust/comments/i4rpyc/why_qemu_shoul...](https://www.reddit.com/r/rust/comments/i4rpyc/why_qemu_should_move_from_c_to_rust/)

------
Thaxll
I think the real benchmark is a large "C" project writen fully in Rust and to
compare the issues on the long term, not sure it's safe to asume that Rust
would fix all the security issues with all the unsafe code that would be?

What a 1.5M LoC Rust low level kind of project looks like?

~~~
staticassertion
Honestly, I think anyone who has written Rust, even low level Rust,
intuitively understands that it wouldn't even be close. It's not really worth
measuring - like measuring C vs Java, no one really needs to do it because
it's so obvious that C will have many times more memory safety issues.

~~~
nullc
Bad science.

Rust code does have unsafe at times, so it can still have memory safety
issues.

It may not matter that your program is memory safe if it was written by people
who don't understand the problem domain and doesn't work correctly. E.g. for
qemu, it's perfectly possible to be absurdly vulnerable -- giving target code
control of the host -- without any memory safety bug at all.

~~~
staticassertion
In fact it's not science at all. I didn't claim it was science, I claimed it
was so obvious and intuitive that science was unnecessary.

> without any memory safety bug at all.

Most QEMU escapes I have seen are memory safety issues in emulated devices.

------
varbhat
Telling QEMU to move from C to Rust is bad idea imo. QEMU Devs are probably
well versed in Source code of QEMU and C. Telling them to learn new language
and rewrite QEMU would be a joke. It would give lot of new problems than
solving the current issues.

Probably, RUST Devs who are well versed in emulation can start another project
in RUST which has same goals of QEMU but telling existing software to rewrite
is a big JOKE to be laughed at.

This has nothing to do with RUST but "Rewrite in New language" syndrome.

~~~
pquerna
Hello.

I'm not a QEMU developer. I used to be pretty active in Apache HTTPD, APR and
related projects. They are large user space code bases written in C - with,
overall, a relatively OK security record.

I think Apache should be on a path to be rewritten in Rust. Here's why...

Every new line of C has a chance of a remotely exploitable vulnerability. No
matter the precautions taken, no matter the developer who writes it. HTTPD has
a long history, precautions like memory pools from APR and uses "safe" string
functions, but it still has issues.

Apache's core C code doesn't change much, so yes, many remotely exploitable
memory corruption bugs have been fixed over 20+ years, but new code, new code
still has bugs. And they can be bad.

Look at the recent known vulnerabilities in httpd:
[https://httpd.apache.org/security/vulnerabilities_24.html](https://httpd.apache.org/security/vulnerabilities_24.html)

Vulns that are largely fixed by Rust are concentrated areas like HTTP/2
support and the Proxy - areas under active development. Vulns around logical
errors are still there, and more widespread, but largely have a lower impact.

So, I emphasize with QEMU developers. I'm in the same boat. I have a full time
job, and that job is not to work on Apache HTTPD. It would take a full time
job to incrementally adopt Rust. The outcome would be in 24+ months, no more
remote memory corruption bugs. Is it worth it to fund this? Can you put a
price tag on this for the dozens of "core infrastructure" software projects
written in C?

~~~
secondcoming
No offense, but rewriting httpd in rust won't make it any better. There's no
excuse for thread-per-connection in 2020.

~~~
fanf2
Good thing Apache has mpm_event
[https://httpd.apache.org/docs/2.4/mod/event.html](https://httpd.apache.org/docs/2.4/mod/event.html)

~~~
pquerna
in a hilarious turn of events (to me at least), I was one of the primary
developers of the event mpm.

~~~
secondcoming
Alright, so please correct me if I'm wrong then.

I cannot perform a non-blocking operation (querying redis for example) from
within my module's handler function because as soon as my handler returns
httpd sends a response. i.e. there's no 'NOT_DONE_YET' return code?

And while I'm anonymously ranting on the internet...

\- being able to control response headers completely would be nice. In our
case, the Date and Server headers cost money to send and our clients don't
care about them. It's not for security reasons, it's about traffic egress
costs on the cloud

\- having a way to hook a worker thread's init would be useful

\- there must be an easier way to get a request body other than the bucket
brigade stuff?

~~~
pquerna
1) You return SUSPENDED instead of OK from your handler. See also
[http://svn.apache.org/viewvc?view=revision&revision=1593860](http://svn.apache.org/viewvc?view=revision&revision=1593860)

2) You can control all response filters at the byte level with an Output
Filter.

3) Hooks already exist for this:
[https://ci.apache.org/projects/httpd/trunk/doxygen/group__ho...](https://ci.apache.org/projects/httpd/trunk/doxygen/group__hooks.html)

4) No. Bucket Brigades is the API for this. It's an efficient linked-list of
future-data. It's a good API IMO, just needs some understanding, and because
its in C, its full of macros (there are more alternatives to making it cleaner
if we weren't using C)

~~~
secondcoming
1) potential gamechanger. Thanks for pointing it out

2) yes, but there's a config directive for the Server header too that could
just allow people to turn it off

3) for child_init, but nothing obvious that maps to a worker_thread_init

Are there plans for httpd to avail of io_uring if the kernel provides it?

I will admit, I've struggled with configuring httpd for years. A single
threaded redis server can handle more connections than a full httpd install.

------
stephc_int13
Rust is the new silver bullet...

~~~
tankenmate
And an easy way to tell is there is no section in the post on what the
downsides are to picking Rust.

~~~
steveklabnik
There may not be an explicit section, but the post certainly talks about how
it would be a mistake to rewrite the code, and gives reasons.

~~~
tankenmate
IMHO that is just a soft touch, it's just saying there might be some areas
where Rust isn't a good fit. What the article doesn't address is what the
intrinsic costs of switching are, as opposed to what the article does address
is that there are probably places where it doesn't have a good fit.

In short the article doesn't address what new costs Rust might bring that are
intrinsic to using Rust (as opposed to costs that are inherent in making a
change to _any_ new language).

------
kasajian
I find it odd that for the solution proposed for solving problems with C that
are explicitly solved by C++ is not to move the code-base to C++ but to an
incompatible language, like Rust. Nothing against Rust, but sounds more like
someone who wants to work on Rust.

~~~
war1025
Wrong thread, fyi.

~~~
dang
We've moved it. Comment was originally posted to
[https://news.ycombinator.com/item?id=24133146](https://news.ycombinator.com/item?id=24133146).

I always wonder about the specifics of how these happen!

~~~
skinkestek
> I always wonder about the specifics of how these happen!

Once I read someone saying they where blind and had forgotten the context or
navigated back or something without noticing. I think there were some
interesting follow up questions as well.

~~~
dang
Exactly—I bet the reasons are often surprising.

------
beeforpork
What's the current state of compilation times of Rust? How many times slower
than C does it compile? Any links to statistics? I know it's hard to compare,
but I am interested in developing a gut feeling of what to expect.

~~~
steveklabnik
> What's the current state of compilation times of Rust?

Still slower than we'd like. Some folks are putting in a heroic amount of
effort to improve this significantly, but it's going to be a long time before
it really happens. Smaller stuff is helping all the time, but has less
dramatic impact.

> How many times slower than C does it compile?

Really impossible to say, because it varies along so many different factors. C
will almost always compile faster though, it's true.

> Any links to statistics? I know it's hard to compare, but I am interested in
> developing a gut feeling of what to expect.

The closest we have is a few bits of basically anecdotal evidence; we have
projects demonstrating that rustc got about 3x faster since 1.0, and we have
had at least one (in my mind) pretty reasonable C++/Rust comparison that
showed them as being roughly equal. But it's just really hard to get good data
here.

You should expect something roughly C++-like.

------
stephc_int13
Well, that would be a nice benchmark ;)

I would be very curious to compare speed, size and compilation time of the two
versions.

------
rvz
_" Talk is cheap, show me the code" \- Linus Torvalds_

The author applies the same standard reasons for moving from C to Rust for the
QEMU project which are valid reasons. However, I would take the author more
seriously if they have done a proof of concept first and then later made their
case for this.

Otherwise, it is another "rewrite it in rust" post which is yet to materialise
into a real project.

~~~
thramp
> Otherwise, it is another "rewrite it in rust" post which is yet to
> materialise into a real project.

I'm not sure you can reasonably said that "it is another 'rewrite it in rust'
post..." if it's coming from a QEMU maintainer.

Besides, before starting a large engineering project like this, it's
worthwhile to write a high-level proposal _then_ write code. Saves you a lot
of wasted effort!

------
GuB-42
Haha, good luck porting QEMU to Rust.

For those who don't know, the original author of QEMU is Fabrice Bellard. This
guy has several winning entries in the IOCCC. One of them is a C compiler,
that once de-obfuscated, forms the basis of TinyCC.

QEMU C code makes heavy use of macros and gcc extensions. It really pushes C
to the limit, it even broke my syntax analysis tools.

Now, if the Rust community wants to write a new emulator in Rust, why not, but
starting with QEMU may not be the easiest way.

------
OnlyOneCannolo
> Eliminating C programming bugs does not necessarily require switching
> programming languages. Other approaches to reducing bug rates in software
> include:

> \- Static checkers that scan source code for bugs.

Does QEMU use a sound static analyzer (like IKOS [1])?

[1] [https://github.com/NASA-SW-VnV/ikos](https://github.com/NASA-SW-VnV/ikos)

~~~
stefanha
No. Coverity scans QEMU regularly but it is not sound.

The challenge with static analyzers is that false positives make people not
want to deal with the analyzer reports.

I will check out IKOS, thanks!

~~~
OnlyOneCannolo
One of the cool things about that particular analyzer is that you can choose
how accurate it is in exchange for how long it takes.

------
greg7mdp
Could the effort be bootstrapped by using a C to Rust translator, like
[https://github.com/immunant/c2rust](https://github.com/immunant/c2rust),
preserving the existing semantics prior to updating the code to remove the
"unsafe" tags.

------
ausjke
C11 has safer version of those bad boys(strcpy_s etc) and gcc/clang is more
powerful about static checking and runtime checking these days, make existing
c code better/safer might be more realistic than rewriting code size of qemu
in rust.

------
jeffreyrogers
Seems a bit silly to rewrite working software in a relatively new language. I
like Rust, but it has its own trade-offs. The big one for QEMU being that QEMU
developers and users tend to know C already and not be familiar with Rust.

~~~
staticassertion
Rewriting the device drivers would be huge. Having been tasked with "Make a
QEMU environment safe against advanced attackers" memory safety issues in
device drivers were _by far_ the most concerning issue, and the hardest to
mitigate.

~~~
jeffreyrogers
Rust definitely has that advantage. The downside is most device driver
programmers know C, not Rust. So if you want other people to work on your
driver you either have to expect them to want to work on it badly enough to
learn Rust or to already know Rust.

------
haolez
I've heard from different sources that QEMU's code is one of the best C code
base available in terms of quality and clarity (and smart tricks!). Tough
call.

------
jksmith
Too bad the C beer-goggles have lasted so long that other great languages
didn't take hold. Don't know about that theorem proving stuff in ATS, but with
some application of hygiene like "if denom <> 0 then" and compile time
prechecks on structures that like every Wirthian language ever has offered,
maybe the computational arts would be further along right now.

Nah, too much trouble. I'd rather not check if denom = 0. Back to writing
autonomous car code!

------
siscia
How big is a device emulation mentioned in the article? How many of them are
necessary?

------
didip
If people are really serious about writing virtualization in Rust, they should
just contribute to firecracker: [https://github.com/firecracker-
microvm/firecracker](https://github.com/firecracker-microvm/firecracker)

~~~
luizfelberti
Firecracker is a really nice project, but the scope really isn't the same as
QEMU, and they are not mutually exclusive projects

------
agumonkey
maybe they can recruit the remacs team

~~~
bananaface
Maybe _remacs_ can recruit the remacs team, frankly

~~~
agumonkey
is remacs looking for itself these days ?

------
microcolonel
Start porting some device emulators, otherwise this is just a waste of time.

------
jedisct1
The best way for QEMU (or anything) to keep improving is to have it written
using the languages and tools that the actual maintainers are the most
comfortable with.

People suggesting rewrites in X/Y/Z are usually not people maintaining these
projects. This is evangelism, but it doesn't help with anything.

~~~
stefanha
Article author here. Thanks for mentioning it, I have updated the article to
clarify that I'm a QEMU maintainer. The article was intended for the QEMU
community but now that it's being discussed more widely it helps to be
explicit about my involvement in QEMU.

------
justapassenger
Be the change you wish to see in the world. Otherwise, posts like that are
mostly people asking others to use same toys as they like.

~~~
stefanha
Article author here. I am already working on Rust code for QEMU :).

The goal of the article is to start a wider discussion in the QEMU community
and encourage others to do the same. I will post more about the things I have
been working on when they are ready.

~~~
justapassenger
Happy to hear that, and I support your effort. If you can show people that
Rust actually works and is better, it will help advance QEMU. It'll be much
more productive discussion, when you have actual data and code to back you up.

------
johnklos
Yes. Let's make things less accessible to everyone. People with less resources
have had it too good for the last decade or so, and our double digit core,
double digit gigabyte memory computers no longer make us feel special, so
let's move software to something even bigger and more bloated than anything
we've ever seen before.

