Re: Why QEMU should move from C to Rust (clickbait alert ;))

[Stefan Hajnoczi]

On Thu, Aug 6, 2020 at 12:08 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> Yes, but I think we'll need put in significant effort to guide / assist
> people in taking this direction, and think about what it means for the
> future of QEMU as a brand and GIT repo.
>
> In many ways it is a good thing if the Rust vhost-user impls are
> all in their own standalone git repos. They're likely to be independent
> codebases, so there's little compelling reason to force them into the
> QEMU git, where they'll have to use QEMU workflow, and QEMU release
> cycle. They're better off free from QEMU where they can choose to adopt
> modern development practices like GitLab merge requests if they
> desire and release on a more frequent cycle than QEMU's 3-times a
> year, etc. Would also make them more appealing for use by alternative
> non-QEMU userspaces for KVM.
>
> The downside is that QEMU git would only contain the "legacy" builtin
> C impls of the devices, and all the "recommended" modern Rust impls
> would be elsewhere. Essentially QEMU would no longer be a self-contained
> provider of the complete solution. Many parts would be disaggregated,
> and users now have the burden of finding all the right pieces to build
> the best solution. We've already seen this to some extent with existing
> vhost-user impls, but it feels like we'd be pushing towards that as a
> more general model for the future which would amplify problems we've
> largely been able to ignore upto now.
>
> I'm not sure what a good answer here is. Perhaps QEMU could try to
> become more of brand for an umbrella project that covers multiple
> independant repos ? eg create new repos under gitlab.com/qemu-project/
> but allow them to work fairly independantly from the main qemu.git ?
> That way we can more easily promote a collection of QEMU repos as
> showing the recommended architecture, without forcing everything
> into qemu.git. We can leverage the QEMU website, wiki and documentation
> in general to showcase the overall solution, while still letting the
> pieces develop independently.

I agree.

Working independently and following Rust conventions ought to work
well for external programs like vhost-user device backends.

It's important that the QEMU source tree builds a complete system. Git
submodules can help with that and are already widely used today.

Stefan