Re: QEMU headers in C++

Re: QEMU headers in C++

[Paolo Bonzini]

On 5/2/24 10:02, Daniel P. Berrangé wrote:
>> Hi QEMU,
>> 
>> I work in Android Studio Emulator and we would like to develop devices
>> in C++. Unfortunately, QEMU headers cannot be used with C++ as is
>> (e.g. they use C++ keywords as variable names or implicitly cast void*
>> to T*).
> 
> NB, in recent past QEMU explicitly eliminated almost[1] all C++ code from
> the tree, because the consensus was to be exlcusively a C project. 
> 
>> Will QEMU be open to accept patches from us to make QEMU headers C++
>> compatible?
> 
> Personally I think that'd be a retrograde step. Any downstream development
> fork that made use of that facility would be not be able to feed changes
> / additions back into upstream QEMU codebase at a later date, without QEMU
> accepting C++ code once again.

That would have to depend on what the C++ code would do.  For example, 
if there is a specific library that we find useful and is written in 
C++, it may be useful to accept C++ code in order to share code with 
other open source projects.  I agree that the chances would be small though.

Anyway, just out of curiosity I tried to see what it would take to 
compile edu.c as C++ code, which I think lets us give a more informed 
answer.

There were a bunch of conflicts with C++ keyword, especially "new", 
"class" and "typename".  Given how common "klass" is already in the QEMU 
code, it would be acceptable to replace "class" with "klass" and 
"typename" with "type_name" or "qom_typename".

"new" is common in .c files but rare in headers; there is one occurrence 
in include/hw/pci/pci.h, and some in include/qemu/atomic.h which is a 
problem anyway (see below).  In my opinion, changing

-bool pci_intx_route_changed(PCIINTxRoute *old, PCIINTxRoute *new);
+bool pci_intx_route_changed(PCIINTxRoute *from, PCIINTxRoute *to);

would not be a huge deal.

In some cases, some of the changes would be good to have anyway, for 
example replacing g_try_malloc0 with g_try_new0 (which, as a side 
effect, eliminates a C++ error for casting void *) as you have in 
include/qemu/bitmap.h.  This is a patch that I would accept right away 
(and I have just sent it to qemu-trivial in fact).

The big things that are left are:

- uses of typeof, _Generic, __builtin_types_compatible_p and 
__builtin_choose_expr, for example in typeof_strip_qual() and 
QEMU_MAKE_LOCKABLE

- QemuLockable also has issues due to compound literals, IIRC

Both of these are really a problem only because thread.h and lockable.h 
are included almost everywhere (e.g. via ratelimit.h -> blockjob.h -> 
block-common.h, or coroutine.h -> block-io.h).  Patches to reduce these 
"rebuild everything" includes would be acceptable and an improvement. 
There is no reason for block-common.h to include blockjob.h, for example.

(For lockable.h, Android Simulator could just wrap most of 
it---everything except struct QemuLockable, probably?---in #ifndef 
__cplusplus.  That patch would not be accepted by QEMU but it would be 
very small and localized).

So my answer is that we can't guarantee that QEMU is compilable as C++, 
but some of the changes are an improvement in general and some are a 
wash.  I think accepting the latter is a small price for Google working 
on upstreaming the changes and contributing the former.

Paolo

> We'll never control what forks can do, and many will never feed back code
> regardless, but IMHO we should be steering external developers in a way
> that keeps open the door for their changes to be merged back upstream.

Re: QEMU headers in C++

[Roman Kiryanov]

Hi Paolo, thank you for looking.

On Thu, May 2, 2024 at 8:19 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> Anyway, just out of curiosity I tried to see what it would take to
> compile edu.c as C++ code, which I think lets us give a more informed
> answer.
>
> There were a bunch of conflicts with C++ keyword, especially "new",
> ...
>
> would not be a huge deal.

Yes, this is what I am talking about.

> So my answer is that we can't guarantee that QEMU is compilable as C++,
> but some of the changes are an improvement in general and some are a
> wash.  I think accepting the latter is a small price for Google working
> on upstreaming the changes and contributing the former.

Sure, we will send the patches.

Regards,
Roman.

QEMU headers in C++

[Roman Kiryanov]

Hi QEMU,

I work in Android Studio Emulator and we would like to develop devices
in C++. Unfortunately, QEMU headers cannot be used with C++ as is
(e.g. they use C++ keywords as variable names or implicitly cast void*
to T*).

Will QEMU be open to accept patches from us to make QEMU headers C++ compatible?

Thank you.

Regards,
Roman.

Re: QEMU headers in C++

[Thomas Huth]

On 02/05/2024 06.40, Roman Kiryanov wrote:
> Hi QEMU,
> 
> I work in Android Studio Emulator and we would like to develop devices
> in C++. Unfortunately, QEMU headers cannot be used with C++ as is
> (e.g. they use C++ keywords as variable names or implicitly cast void*
> to T*).

Can't you simply use something like:

extern "C" {
#include <foo.h>
}

to include the QEMU headers?

  Thomas

Re: QEMU headers in C++

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

On Thu, May 2, 2024 at 12:20 AM Thomas Huth <thuth@redhat.com> wrote:

> On 02/05/2024 06.40, Roman Kiryanov wrote:
> > Hi QEMU,
> >
> > I work in Android Studio Emulator and we would like to develop devices
> > in C++. Unfortunately, QEMU headers cannot be used with C++ as is
> > (e.g. they use C++ keywords as variable names or implicitly cast void*
> > to T*).
>
> Can't you simply use something like:
>
> extern "C" {
> #include <foo.h>
> }
>
> to include the QEMU headers?
>

No.

All that does is not mangle the functions and requires that none of them be
overloaded.
It doesn't otherwise change the language that you're compiling, so the
implicit casts
from void * to T * are still verboten. It also doesn't change the keywords
that are accepted.

I'm not in the main line of qemu development, but I'll share what FreeBSD
has done in
this area. We've bracketed the functions in our .h files with __BEGIN_DECLS
/ __END_DECLS
which are defined away in C but not C++ (to allow it to turn into extern
"C" { and } respectively).
We avoid C++ keywords (mostly the word class). Our headers don't have a lot
of inlines in them,
but the few that do we'll make sure they don't have the implicit casts
(though the style we inherited
from CSRG / Research Unix was to always cast). For FreeBSD, we have about a
dozen different
compilation environments that we need to work in, so we also have a bunch
of other macros that
let us use newer C features in headers, but that make them disappear when
someone is building
a pure C90 program. These are quite a bit more intrusive, imho, but still
not bad. So maybe that
context might explain why my initial reaction was "oh, that's not too bad".

If you didn't want to do the __BEGIN_DECLS / __END_DECLS dance (which isn't
a super unreasonable
position), then avoiding keywords is easy enough and usually unobtrusive...
but the implicit cast bits
might be harder to deal with if there's a lot of code that does it.

The hardest part for us has been keeping things working with C++. Though
90% of it naturally is tested
in building FreeBSD because we have just enough C++ that's old-school
enough to include many of
the system headers :). QEMU would need to test it, and that might otherwise
require a C++ compiler
for some builds that wouldn't need one today.

I don't know if the main line developers would be willing to pay this "tax"
or not. I'm not advocating
either way, per se, but would suggest that if the tax is super low and the
benefit to others high, I'd
go for it. In the absence of the scope of the patches, though, it's hard to
say of this amount of C++
would enable more technology than it inhibits by being a drag on future
development.

Warner

[-- Attachment #2: Type: text/html, Size: 3564 bytes --]

Re: QEMU headers in C++

[Daniel P. Berrangé]

On Wed, May 01, 2024 at 09:40:16PM -0700, Roman Kiryanov wrote:
> Hi QEMU,
> 
> I work in Android Studio Emulator and we would like to develop devices
> in C++. Unfortunately, QEMU headers cannot be used with C++ as is
> (e.g. they use C++ keywords as variable names or implicitly cast void*
> to T*).

NB, in recent past QEMU explicitly eliminated almost[1] all C++ code from
the tree, because the consensus was to be exlcusively a C project. 

> Will QEMU be open to accept patches from us to make QEMU headers C++
> compatible?

Personally I think that'd be a retrograde step. Any downstream development
fork that made use of that facility would be not be able to feed changes
/ additions back into upstream QEMU codebase at a later date, without QEMU
accepting C++ code once again.

We'll never control what forks can do, and many will never feed back code
regardless, but IMHO we should be steering external developers in a way
that keeps open the door for their changes to be merged back upstream.

With regards,
Daniel

[1] Only some minor windows installer code remains C++.
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: QEMU headers in C++

[Peter Maydell]

On Thu, 2 May 2024 at 09:02, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, May 01, 2024 at 09:40:16PM -0700, Roman Kiryanov wrote:
> > Hi QEMU,
> >
> > I work in Android Studio Emulator and we would like to develop devices
> > in C++. Unfortunately, QEMU headers cannot be used with C++ as is
> > (e.g. they use C++ keywords as variable names or implicitly cast void*
> > to T*).
>
> NB, in recent past QEMU explicitly eliminated almost[1] all C++ code from
> the tree, because the consensus was to be exlcusively a C project.
>
> > Will QEMU be open to accept patches from us to make QEMU headers C++
> > compatible?
>
> Personally I think that'd be a retrograde step. Any downstream development
> fork that made use of that facility would be not be able to feed changes
> / additions back into upstream QEMU codebase at a later date, without QEMU
> accepting C++ code once again.
>
> We'll never control what forks can do, and many will never feed back code
> regardless, but IMHO we should be steering external developers in a way
> that keeps open the door for their changes to be merged back upstream.

Yes, I agree. If you try to write device models in C++ then you're
pretty heavily committing to never being able to upstream this stuff,
plus you'll have a chunk of your codebase which is entirely
"nobody else in the world does this this way". I really wouldn't
recommend that.

thanks
-- PMM