[Qemu-devel] Suggestions

[Qemu-devel] Suggestions

[Kent Harris]

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

Hi folks,

I'm not up to speed enough to feel comfortable submitting patches but  
I have noticed a couple issues and thought you might be interested.   
Some of us develop custom devices in C++ and need to include qemu  
header files into C++ source.

cpu-all.h:  some of the casts were removed when converting from "void  
*".  C compilers are fine with this but C++ compilers are not:
--- vm/qemu-current/cpu-all.h.orig  2009-05-14 11:08:55.829774000 -0700
+++ vm/qemu-current/cpu-all.h   2009-05-14 11:10:08.055136000 -0700
@@ -415,7 +415,7 @@
                    : "m" (*(uint16_t *)ptr));
      return val;
  #else
-    const uint8_t *b = ptr;
+    const uint8_t *b = (const uint8_t *)ptr;
      return ((b[0] << 8) | b[1]);
  #endif
  }
@@ -430,7 +430,7 @@
                    : "m" (*(uint16_t *)ptr));
      return (int16_t)val;
  #else
-    const uint8_t *b = ptr;
+    const uint8_t *b = (const uint8_t *)ptr;
      return (int16_t)((b[0] << 8) | b[1]);
  #endif
  }


net.h:  looks like a structure member "void *private" was added.  C++  
compilers will not accept this since "public", "protected", and  
"private" are keywords to denote scope.  This problem may exist in  
other header files.

Thanks,

Kent

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

Re: [Qemu-devel] Suggestions

[Anthony Liguori]

Kent Harris wrote:
> Hi folks,
>
> I'm not up to speed enough to feel comfortable submitting patches but 
> I have noticed a couple issues and thought you might be interested. 
>  Some of us develop custom devices in C++ and need to include qemu 
> header files into C++ source.

I don't think we're ever going to support C++ devices in QEMU so it's 
unlikely that we would make such changes.

Regards,

Anthony Liguori

Re: [Qemu-devel] Suggestions

[Kent Harris]

Anthony,

Give me a moment of your time to see if I can convince you otherwise.   
I appreciate the difficulty in catering to every Tom, Dick, and  
Harry's request for support.

I build extremely complex embedded systems where procedural  
programming and methodologies like functional decomposition are not  
practical.  I build large information models in advance of coding and  
then use an object-oriented (OO) language to implement the models, in  
this case C++.  Inheritance hierarchies, instantiation relationships,  
compositional relationships, etc. are all modeled in advance (I don't  
use a tool, just paper, pencil, and thinking.)  Programming in a non- 
OO language would be beyond painful.

The delta you have right now between what you have and what C++ needs  
is only a handful of source lines and the changes are trivial.  If you  
choose not to accommodate such you will blocking all the folks who  
need OO development methodologies.

QEMU is a wonderful technology and you have done a remarkable job in  
creating and promoting it.  I wouldn't ask if the task to support C++  
were significant but as the delta is so small you would be opening  
QEMU up to the embedded folks like myself who use lesser known  
operating systems and need to create behavioral models of complex  
devices.

Thanks for your time, I won't bug you anymore.

- Kent Harris

On May 14, 2009, at 2:35 PM, Anthony Liguori wrote:

> Kent Harris wrote:
>> Hi folks,
>>
>> I'm not up to speed enough to feel comfortable submitting patches  
>> but I have noticed a couple issues and thought you might be  
>> interested.  Some of us develop custom devices in C++ and need to  
>> include qemu header files into C++ source.
>
> I don't think we're ever going to support C++ devices in QEMU so  
> it's unlikely that we would make such changes.
>
> Regards,
>
> Anthony Liguori

Re: [Qemu-devel] Suggestions

[andrzej zaborowski]

2009/5/14 Kent Harris <ksh@vine.com>:
> net.h:  looks like a structure member "void *private" was added.  C++
> compilers will not accept this since "public", "protected", and "private"
> are keywords to denote scope.  This problem may exist in other header files.

You can use
extern "C" { }
around the #includes of the C files in your C++ code if you don't need
to access the fields named with C++ keywords (if you do, you might
need to #define them to something before the #include).

Cheers