Re: KVM call for 2017-03-14

From: Juan Quintela <quintela@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developer <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>
Subject: Re: KVM call for 2017-03-14
Date: Tue, 14 Mar 2017 09:53:17 +0100	[thread overview]
Message-ID: <871su0utmq.fsf@secure.mitica> (raw)
In-Reply-To: <20170314081312.GB13140@stefanha-x1.localdomain> (Stefan Hajnoczi's message of "Tue, 14 Mar 2017 16:13:12 +0800")

Stefan Hajnoczi <stefanha@gmail.com> wrote:

>>   - on the "VM support" side, QEMU is more used because it's the only
>>     production-quality option in this space, rather than because its
>>     users love it. (cf the Google choice to replace it.) It's also got
>>     a pretty poor security record. It wouldn't be too surprising if
>>     some time in the next five years somebody writes a replacement in
>>     a safer language (perhaps also targeting only the VM support role)
>>     and it got enough mindshare and takeup to eclipse QEMU.
>>     [Is it too early/daft to think about prototyping being able to
>>      write QEMU device emulation in Rust ?]
>
> We can move to a safer language starting with the device emulation
> layer.  Keep the rest in C for now.  Use a language that has good C
> interoperability or a convenient foreign function interface.
>
> Start writing new device models in the new language.  Convert existing
> devices if they are good candidates, like the e1000 NIC emulation.
>
> The minimum requirements for the new language:
> 1. Does it support the host operating systems that QEMU runs on?
> 2. Does it support the host architectures that QEMU runs on?
> 3. Is it safer than C even when writing code to operate on guest RAM
>    (i.e. it's no good if you must use unsafe primitives to do the
>    systems programming tasks that QEMU requires)?
> 4. Is C interoperability convenient and high performance?

That is one approach.  Other is to move to a "safer" language the parts
that are not performance sensitive.  Our command line parsing and device
object done is C just make things much, much worse for no gain.  A
language better for dealing with strings and things like that?

Later, Juan.

PD.  And before anyone asked, a language that is not able to get right:
   a = "hello"
   b = "world"
   c = a + " " + b

   (put any syntax you like) without having to wonder about memory
   allocation, sizes, etc is not really valid to work with strings IMHO.