From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Sergio Lopez <slp@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] is anybody experimenting with the idea of rust code in QEMU?
Date: Wed, 22 May 2019 14:52:03 +0100 [thread overview]
Message-ID: <20190522135203.GE2666@work-vm> (raw)
In-Reply-To: <95f2e1c8-5307-9aa0-601a-e4ee53c199fb@redhat.com>
* Paolo Bonzini (pbonzini@redhat.com) wrote:
> On 22/05/19 14:53, Stefan Hajnoczi wrote:
> > On Tue, May 21, 2019 at 03:39:40PM +0100, Peter Maydell wrote:
> >> Hi; I have on my todo list the idea of some experimentation/prototyping
> >> of whether being able to write some components of QEMU in Rust would
> >> be (a) feasible (b) beneficial (c) fun to play around with even if
> >> it is likely that it doesn't go anywhere :-)
> >>
> >> I know Paolo has had a look at how you might write some makefiles
> >> to integrate rust into a C program (https://github.com/bonzini/rust-and-c/).
> >> Has anybody else been doing anything in this general area ?
> >>
> >> (I went to two good talks locally recently about rust-vmm and Amazon's
> >> 'firecracker' VMM by Andreea Florescu and Diana Popa -- I
> >> definitely plan to look at rust-vmm as part of this.)
> >
> > There are some in-development vhost-user device backends in Rust.
> > Sergio Lopez is working on a vhost-user-blk implementation. David
> > Gilbert is working on a vhost-user-fs implementation.
> >
> > I think mixing Rust and C code in the main QEMU binary itself is
> > probably more trouble than it's worth. Think boilerplate, duplication,
> > coming up with safe Rust APIs for QEMU's unsafe APIs.
>
> This is true. The case I was playing with is where the QEMU APIs have a
> more or less direct mapping to rust-vmm APIs and only have a limited
> number of dependencies on other C APIs. This way, you can either write
> a Rust binding to the C code, or rewrite the C code in Rust with tiny C
> wrapper APIs on top.
>
> For example, the memory API (more or less) depends only on RCU and maps
> to rust-vmm/vm-memory, and virtqueue processing in rust-vmm/vm-virtio
> depends only on the memory API.
The other place might be places where we're autogenerating the C
interfaces anyway - e.g. we could autogenerate rust bindings for qapi.
Dave
> Thanks,
>
> Paolo
>
> > I'm more interested in using Rust for separate processes that can be
> > written from scratch.
> >
> > Stefan
> >
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
prev parent reply other threads:[~2019-05-22 13:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-21 14:39 [Qemu-devel] is anybody experimenting with the idea of rust code in QEMU? Peter Maydell
2019-05-21 14:48 ` Paolo Bonzini
2019-05-21 15:15 ` Marc-André Lureau
2019-05-22 12:53 ` Stefan Hajnoczi
2019-05-22 13:28 ` Paolo Bonzini
2019-05-22 13:52 ` Dr. David Alan Gilbert [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:
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=20190522135203.GE2666@work-vm \
--to=dgilbert@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=slp@redhat.com \
--cc=stefanha@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.