[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Block layer complexity: what to do to keep it under con
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] Block layer complexity: what to do to keep it under control? |
Date: |
Mon, 4 Dec 2017 10:41:55 +0000 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
On Fri, Dec 01, 2017 at 07:03:15PM +0000, Peter Maydell wrote:
> On 1 December 2017 at 17:03, Paolo Bonzini <address@hidden> wrote:
> > Same here. Just like fixing the C code provides a good foundation for a
> > language switch, some more battle-tested code could be converted from
> > QEMU to Rust, in order to get familiar with it and probe whether the
> > benefits are real. Maybe the memory API could be a good candidate; it
> > certainly would benefit from generics.
>
> At the moment I feel like betting the future of the project on
> Rust would be quite a courageous decision. On the other hand
> it might be interesting to look at prototyping to see what
> benefits it might bring. (One candidate I had in mind was the
> device API -- given that we have had quite a few buffer overruns
> in device code, converting some of the device models to Rust
> might cut off that particular security issue.)
>
> I agree with you that trying to tackle conversion without at
> least one developer with reasonably-expert Rust knowledge is
> likely to be fraught, though -- what you really need is to be
> able to design APIs which are idiomatic for the language, rather
> than the kind of thing you'd write in C but transliterated across...
My main concern beyond lack of Rust experience is that quite a bit of
glue code is necessary to mix Rust and C:
https://doc.rust-lang.org/book/first-edition/ffi.html
You need to redefine structs and functions in Rust. To make the C
functions easily callable from Rust without unsafe code, you then need
to write Rust wrapper functions.
This means a lot of boilerplate and duplication. It makes documenting
code harder.
IMO it will be very hard to replace a component in the QEMU codebase
with Rust code unless we're willing to put up with a lot of boilerplate
and duplication.
Where Rust makes a lot of sense to me is for new programs like
qemu-pr-helper, vhost-user programs, etc. They have a clearly-defined
boundary (command-line, socket protocol, etc) where switching to Rust
doesn't require redeclaring a bunch of existing C interfaces.
Stefan
signature.asc
Description: PGP signature
- Re: [Qemu-devel] Block layer complexity: what to do to keep it under control?, Fam Zheng, 2017/12/01
- Re: [Qemu-devel] Block layer complexity: what to do to keep it under control?, Stefan Hajnoczi, 2017/12/01
- Re: [Qemu-devel] Block layer complexity: what to do to keep it under control?, Fam Zheng, 2017/12/01
- Re: [Qemu-devel] Block layer complexity: what to do to keep it under control?, Paolo Bonzini, 2017/12/01
- Re: [Qemu-devel] Block layer complexity: what to do to keep it under control?, Eric Blake, 2017/12/01
- Re: [Qemu-devel] Block layer complexity: what to do to keep it under control?, Stefan Hajnoczi, 2017/12/04
- Re: [Qemu-devel] Block layer complexity: what to do to keep it under control?, Peter Maydell, 2017/12/04