[Qemu-devel] Unmaintained QEMU builds

[Qemu-devel] Unmaintained QEMU builds

[Stefan Weil]

Hi,

since several months, QEMU for Windows (and mingw32 cross builds)
no longer builds without error.

I suspect that the same is true for QEMU on Darwin (lots of errors like
darwin-user/qemu.h:149: error: cast to pointer from integer of different 
size),
but I'm not sure here because I have no valid Darwin test environment.
Maybe someone can test this.

What about these environments? They have no maintainers.
Should they be marked as unsupported? Are they still used?
Or should they be removed?

Regards
Stefan

Fwd: [Qemu-devel] Unmaintained QEMU builds

[Matthijs ter Woord]

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

Stefan,
Sorry for directly replying. Resending to list:

At least QEMU for windows has some serious bugs, related to GDB handling,
and serial handling..



On Wed, Aug 11, 2010 at 12:58 PM, Stefan Weil <weil@mail.berlios.de> wrote:

> Hi,
>
> since several months, QEMU for Windows (and mingw32 cross builds)
> no longer builds without error.
>
> I suspect that the same is true for QEMU on Darwin (lots of errors like
> darwin-user/qemu.h:149: error: cast to pointer from integer of different
> size),
> but I'm not sure here because I have no valid Darwin test environment.
> Maybe someone can test this.
>
> What about these environments? They have no maintainers.
> Should they be marked as unsupported? Are they still used?
> Or should they be removed?
>
> Regards
> Stefan
>
>
>

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

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil <weil@mail.berlios.de> wrote:
> Hi,
>
> since several months, QEMU for Windows (and mingw32 cross builds)
> no longer builds without error.

Not true for mingw32, it was building fine here until the latest commit.

> I suspect that the same is true for QEMU on Darwin (lots of errors like
> darwin-user/qemu.h:149: error: cast to pointer from integer of different
> size),
> but I'm not sure here because I have no valid Darwin test environment.
> Maybe someone can test this.
>
> What about these environments? They have no maintainers.
> Should they be marked as unsupported? Are they still used?
> Or should they be removed?

I compile test mingw32 very often, it's part of my build test setup.
If the build breaks, I may even fix the problem.

But perhaps darwin-user should be removed.

Re: [Qemu-devel] Unmaintained QEMU builds

[Stefan Weil]

Am 11.08.2010 18:34, schrieb Blue Swirl:
> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil <weil@mail.berlios.de> 
> wrote:
>> Hi,
>>
>> since several months, QEMU for Windows (and mingw32 cross builds)
>> no longer builds without error.
>
> Not true for mingw32, it was building fine here until the latest commit.

That's a big surprise! Do you have a mingw32 version which includes 
setenv()?
My Debian mingw32-runtime 3.13-1 does not support setenv(), so
compilation gives a warning and linking gives an error.

And don't you get warnings from SDL headers which redefine
WIN32_LEAN_AND_MEAN?

>
>> I suspect that the same is true for QEMU on Darwin (lots of errors like
>> darwin-user/qemu.h:149: error: cast to pointer from integer of different
>> size),
>> but I'm not sure here because I have no valid Darwin test environment.
>> Maybe someone can test this.
>>
>> What about these environments? They have no maintainers.
>> Should they be marked as unsupported? Are they still used?
>> Or should they be removed?
>
> I compile test mingw32 very often, it's part of my build test setup.
> If the build breaks, I may even fix the problem.
>
> But perhaps darwin-user should be removed.
>

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

On Wed, Aug 11, 2010 at 6:18 PM, Stefan Weil <weil@mail.berlios.de> wrote:
> Am 11.08.2010 18:34, schrieb Blue Swirl:
>>
>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil <weil@mail.berlios.de>
>> wrote:
>>>
>>> Hi,
>>>
>>> since several months, QEMU for Windows (and mingw32 cross builds)
>>> no longer builds without error.
>>
>> Not true for mingw32, it was building fine here until the latest commit.
>
> That's a big surprise! Do you have a mingw32 version which includes
> setenv()?
> My Debian mingw32-runtime 3.13-1 does not support setenv(), so
> compilation gives a warning and linking gives an error.
>
> And don't you get warnings from SDL headers which redefine
> WIN32_LEAN_AND_MEAN?

No, I have even configured with --enable-werror. But it looks like I
have forgotten to make SDL headers available. I think SDL with mingw32
worked at some point, VNC is still fine.

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

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

On Wed, Aug 11, 2010 at 6:51 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Wed, Aug 11, 2010 at 6:18 PM, Stefan Weil <weil@mail.berlios.de> wrote:
>> Am 11.08.2010 18:34, schrieb Blue Swirl:
>>>
>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil <weil@mail.berlios.de>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> since several months, QEMU for Windows (and mingw32 cross builds)
>>>> no longer builds without error.
>>>
>>> Not true for mingw32, it was building fine here until the latest commit.
>>
>> That's a big surprise! Do you have a mingw32 version which includes
>> setenv()?
>> My Debian mingw32-runtime 3.13-1 does not support setenv(), so
>> compilation gives a warning and linking gives an error.
>>
>> And don't you get warnings from SDL headers which redefine
>> WIN32_LEAN_AND_MEAN?
>
> No, I have even configured with --enable-werror. But it looks like I
> have forgotten to make SDL headers available. I think SDL with mingw32
> worked at some point, VNC is still fine.

With these changes, build succeeds with SDL. For example,
qemu-system-sparc.exe can boot from a Sparc32 CD under Wine.

[-- Attachment #2: 0001-Fix-mingw32-warnings-with-SDL.patch --]
[-- Type: application/mbox, Size: 1347 bytes --]

Re: [Qemu-devel] Unmaintained QEMU builds

[Stefan Weil]

Am 11.08.2010 21:19, schrieb Blue Swirl:
> On Wed, Aug 11, 2010 at 6:51 PM, Blue Swirl<blauwirbel@gmail.com>  wrote:
>    
>> On Wed, Aug 11, 2010 at 6:18 PM, Stefan Weil<weil@mail.berlios.de>  wrote:
>>      
>>> Am 11.08.2010 18:34, schrieb Blue Swirl:
>>>        
>>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil<weil@mail.berlios.de>
>>>> wrote:
>>>>          
>>>>> Hi,
>>>>>
>>>>> since several months, QEMU for Windows (and mingw32 cross builds)
>>>>> no longer builds without error.
>>>>>            
>>>> Not true for mingw32, it was building fine here until the latest commit.
>>>>          
>>> That's a big surprise! Do you have a mingw32 version which includes
>>> setenv()?
>>> My Debian mingw32-runtime 3.13-1 does not support setenv(), so
>>> compilation gives a warning and linking gives an error.
>>>
>>> And don't you get warnings from SDL headers which redefine
>>> WIN32_LEAN_AND_MEAN?
>>>        
>> No, I have even configured with --enable-werror. But it looks like I
>> have forgotten to make SDL headers available. I think SDL with mingw32
>> worked at some point, VNC is still fine.
>>      
> With these changes, build succeeds with SDL. For example,
> qemu-system-sparc.exe can boot from a Sparc32 CD under Wine.
>    

Yes, that's a possible solution.

You could also take these patches which I sent to qemu-devel:

http://patchwork.ozlabs.org/patch/49217/
http://patchwork.ozlabs.org/patch/57532/

Regards
Stefan

[Qemu-devel] Re: Unmaintained QEMU builds

[Paolo Bonzini]

On 08/11/2010 03:37 PM, Stefan Weil wrote:
>> With these changes, build succeeds with SDL. For example,
>> qemu-system-sparc.exe can boot from a Sparc32 CD under Wine.
>
> Yes, that's a possible solution.
>
> You could also take these patches which I sent to qemu-devel:
>
> http://patchwork.ozlabs.org/patch/49217/
> http://patchwork.ozlabs.org/patch/57532/

The latter change is already in Blue Swirl's patch.

The former is for the setenv issue.  Jes Sorensen asked you to make some 
changes, and you never replied; this is the best way to keep your patch 
*out* of the tree.  Blue Swirl patch is suboptimal with respect to 
setenv, because the setenv is actually useful under Win32, but I still 
think it should go in---and then you can fix it in a better way if you 
want to follow the rules of the community.

Paolo

[Qemu-devel] Re: Unmaintained QEMU builds

[Stefan Weil]

Am 12.08.2010 00:12, schrieb Paolo Bonzini:
> On 08/11/2010 03:37 PM, Stefan Weil wrote:
>>> With these changes, build succeeds with SDL. For example,
>>> qemu-system-sparc.exe can boot from a Sparc32 CD under Wine.
>>
>> Yes, that's a possible solution.
>>
>> You could also take these patches which I sent to qemu-devel:
>>
>> http://patchwork.ozlabs.org/patch/49217/
>> http://patchwork.ozlabs.org/patch/57532/
>
> The latter change is already in Blue Swirl's patch.
>
> The former is for the setenv issue.  Jes Sorensen asked you to make 
> some changes, and you never replied; this is the best way to keep your 
> patch *out* of the tree.  Blue Swirl patch is suboptimal with respect 
> to setenv, because the setenv is actually useful under Win32, but I 
> still think it should go in---and then you can fix it in a better way 
> if you want to follow the rules of the community.
>
> Paolo
>

Hello Paolo,

Jes has an opinion how thinks should be done, and I have a different one.
If you read the complete history, you can see that I suggested a 
compromise (*)
which would give the same result as Jes' suggestions. Only the steps
to reach this result were different, and I have good reasons why I
prefer my way to do them. Both ways require two commits, so
there would be no difference for the community nor for the
committers.

I did not reply to Jes' last mail because he claims to represent the
community without accepting that others (in this case me) who are
also part of the community might have good reason for their approach, too.
His mail was also very impolite which is one more reason why I
did not reply.

Regards
Stefan

(*) http://lists.nongnu.org/archive/html/qemu-devel/2010-07/msg00054.html

[Qemu-devel] Re: Unmaintained QEMU builds

[Paolo Bonzini]

On 08/12/2010 05:17 AM, Stefan Weil wrote:
> Jes has an opinion how thinks should be done, and I have a different one.
> If you read the complete history, you can see that I suggested a
> compromise (*)
> which would give the same result as Jes' suggestions. Only the steps
> to reach this result were different, and I have good reasons why I
> prefer my way to do them. Both ways require two commits, so
> there would be no difference for the community nor for the
> committers.

I may even agree with you, but if nobody takes the effort to continue a 
discussion you have to proceed as if everyone agreed with Jes.  In 
particular, the patch would have been so easy to redo along those lines, 
that IMHO it wasn't worthwhile arguing.

Paolo

Re: [Qemu-devel] Unmaintained QEMU builds

[Andreas Färber]

Hi,

Am 11.08.2010 um 12:58 schrieb Stefan Weil:

> since several months, QEMU for Windows (and mingw32 cross builds)
> no longer builds without error.
>
> I suspect that the same is true for QEMU on Darwin (lots of errors  
> like
> darwin-user/qemu.h:149: error: cast to pointer from integer of  
> different size),
> but I'm not sure here because I have no valid Darwin test environment.
> Maybe someone can test this.
>
> What about these environments? They have no maintainers.
> Should they be marked as unsupported? Are they still used?
> Or should they be removed?

I just updated, and it does fail to link on OSX:

   LINK  i386-softmmu/qemu
Undefined symbols:
   "_kvm_set_ioeventfd_mmio_long", referenced from:
       _ivshmem_read in ivshmem.o
       _ivshmem_read in ivshmem.o
       _ivshmem_mmio_map in ivshmem.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [qemu] Error 1
make: *** [subdir-i386-softmmu] Error 2

Please don't remove. :) Hints for patches are welcome.

darwin-user is another matter, it was broken ever since I use QEMU and  
my half-hearted attempts to fix were unsuccessful.

Andreas

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

Thanks, applied both.

On Wed, Aug 11, 2010 at 7:37 PM, Stefan Weil <weil@mail.berlios.de> wrote:
> Am 11.08.2010 21:19, schrieb Blue Swirl:
>>
>> On Wed, Aug 11, 2010 at 6:51 PM, Blue Swirl<blauwirbel@gmail.com>  wrote:
>>
>>>
>>> On Wed, Aug 11, 2010 at 6:18 PM, Stefan Weil<weil@mail.berlios.de>
>>>  wrote:
>>>
>>>>
>>>> Am 11.08.2010 18:34, schrieb Blue Swirl:
>>>>
>>>>>
>>>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil<weil@mail.berlios.de>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> since several months, QEMU for Windows (and mingw32 cross builds)
>>>>>> no longer builds without error.
>>>>>>
>>>>>
>>>>> Not true for mingw32, it was building fine here until the latest
>>>>> commit.
>>>>>
>>>>
>>>> That's a big surprise! Do you have a mingw32 version which includes
>>>> setenv()?
>>>> My Debian mingw32-runtime 3.13-1 does not support setenv(), so
>>>> compilation gives a warning and linking gives an error.
>>>>
>>>> And don't you get warnings from SDL headers which redefine
>>>> WIN32_LEAN_AND_MEAN?
>>>>
>>>
>>> No, I have even configured with --enable-werror. But it looks like I
>>> have forgotten to make SDL headers available. I think SDL with mingw32
>>> worked at some point, VNC is still fine.
>>>
>>
>> With these changes, build succeeds with SDL. For example,
>> qemu-system-sparc.exe can boot from a Sparc32 CD under Wine.
>>
>
> Yes, that's a possible solution.
>
> You could also take these patches which I sent to qemu-devel:
>
> http://patchwork.ozlabs.org/patch/49217/
> http://patchwork.ozlabs.org/patch/57532/
>
> Regards
> Stefan
>
>

Re: [Qemu-devel] Unmaintained QEMU builds

[Anthony Liguori]

On 08/11/2010 11:34 AM, Blue Swirl wrote:
> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil<weil@mail.berlios.de>  wrote:
>    
>> Hi,
>>
>> since several months, QEMU for Windows (and mingw32 cross builds)
>> no longer builds without error.
>>      
> Not true for mingw32, it was building fine here until the latest commit.
>
>    
>> I suspect that the same is true for QEMU on Darwin (lots of errors like
>> darwin-user/qemu.h:149: error: cast to pointer from integer of different
>> size),
>> but I'm not sure here because I have no valid Darwin test environment.
>> Maybe someone can test this.
>>
>> What about these environments? They have no maintainers.
>> Should they be marked as unsupported? Are they still used?
>> Or should they be removed?
>>      
> I compile test mingw32 very often, it's part of my build test setup.
> If the build breaks, I may even fix the problem
>    

But do you do any testing with the Windows build?

Historically, even when Windows builds, it spends large periods of time 
not actually working.  I think Stefan can confirm this.  Much of the 
platform specific code is way behind (like the block layer) and has been 
for many years.

I can't remember the last time someone sent a Win32 enhancement for 
platform code.

Given that it's known to have a lot of issues, I would suggest that we 
schedule Windows host support for deprecation in 0.15.  I would not 
recommend that we remove any of the WIN32 code from the build but 
basically stop trying to make it even build until someone steps up to 
really actively maintain and enhance the Windows port.  I would still 
suggest we take patches if anyone wants to submit them but we should not 
avoid patches that are known to break win32 (unless the fix is trivial).

For instance, I know that some downstreams (like Android) depend heavily 
on Win32 so an official statement of deprecation might cause them to 
push some of their fixes upstream and be more active in upstream 
maintenance.

Regards,

Anthony Liguori

> But perhaps darwin-user should be removed.
>
>    

[Qemu-devel] Re: Unmaintained QEMU builds

[Paolo Bonzini]

On 08/15/2010 11:42 PM, Anthony Liguori wrote:
> Given that it's known to have a lot of issues, I would suggest that we
> schedule Windows host support for deprecation in 0.15. I would not
> recommend that we remove any of the WIN32 code from the build but
> basically stop trying to make it even build until someone steps up to
> really actively maintain and enhance the Windows port. I would still
> suggest we take patches if anyone wants to submit them but we should not
> avoid patches that are known to break win32 (unless the fix is trivial).

I was planning to submit a qemu-thread port for Win32 for 0.14, which of 
course means doing some basic sanity testing of the port.  However, I'm 
not in any way trying to support anything more complicated than raw 
images and SDL/VNC.  In particular, I'm not going to test networking.

Paolo

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 08/11/2010 11:34 AM, Blue Swirl wrote:
>>
>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil<weil@mail.berlios.de>
>>  wrote:
>>
>>>
>>> Hi,
>>>
>>> since several months, QEMU for Windows (and mingw32 cross builds)
>>> no longer builds without error.
>>>
>>
>> Not true for mingw32, it was building fine here until the latest commit.
>>
>>
>>>
>>> I suspect that the same is true for QEMU on Darwin (lots of errors like
>>> darwin-user/qemu.h:149: error: cast to pointer from integer of different
>>> size),
>>> but I'm not sure here because I have no valid Darwin test environment.
>>> Maybe someone can test this.
>>>
>>> What about these environments? They have no maintainers.
>>> Should they be marked as unsupported? Are they still used?
>>> Or should they be removed?
>>>
>>
>> I compile test mingw32 very often, it's part of my build test setup.
>> If the build breaks, I may even fix the problem
>>
>
> But do you do any testing with the Windows build?

Sometime I do a boot test with Wine.

> Historically, even when Windows builds, it spends large periods of time not
> actually working.  I think Stefan can confirm this.  Much of the platform
> specific code is way behind (like the block layer) and has been for many
> years.
>
> I can't remember the last time someone sent a Win32 enhancement for platform
> code.
>
> Given that it's known to have a lot of issues, I would suggest that we
> schedule Windows host support for deprecation in 0.15.  I would not
> recommend that we remove any of the WIN32 code from the build but basically
> stop trying to make it even build until someone steps up to really actively
> maintain and enhance the Windows port.  I would still suggest we take
> patches if anyone wants to submit them but we should not avoid patches that
> are known to break win32 (unless the fix is trivial).

The same strategy applied to all hosts would probably eventually break
everything but Linux on x86 with KVM. There have been very few patches
for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host
CPUs. Without Darwin or BSD host support, darwin-user and bsd-user
will be useless. When did we get Xen patches last time before the
recent patch set?

What about other uncommon and possibly already broken (or never
finished) features, like Parallels, VVFAT or VMDK support? What about
new features, do we know in advance that they will be actively
maintained?

But I'm not completely against this. Maybe we should make a list of
features and check which of those work. Features which don't pass are
scheduled for deprecation or removal.

> For instance, I know that some downstreams (like Android) depend heavily on
> Win32 so an official statement of deprecation might cause them to push some
> of their fixes upstream and be more active in upstream maintenance.

We haven't received any patches from VirtualBox downstream either, but
maybe they are still using 0.9.0, so they don't have any.

Re: [Qemu-devel] Unmaintained QEMU builds

[Anthony Liguori]

On 08/16/2010 01:51 PM, Blue Swirl wrote:
> On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 08/11/2010 11:34 AM, Blue Swirl wrote:
>>      
>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil<weil@mail.berlios.de>
>>>   wrote:
>>>
>>>        
>>>> Hi,
>>>>
>>>> since several months, QEMU for Windows (and mingw32 cross builds)
>>>> no longer builds without error.
>>>>
>>>>          
>>> Not true for mingw32, it was building fine here until the latest commit.
>>>
>>>
>>>        
>>>> I suspect that the same is true for QEMU on Darwin (lots of errors like
>>>> darwin-user/qemu.h:149: error: cast to pointer from integer of different
>>>> size),
>>>> but I'm not sure here because I have no valid Darwin test environment.
>>>> Maybe someone can test this.
>>>>
>>>> What about these environments? They have no maintainers.
>>>> Should they be marked as unsupported? Are they still used?
>>>> Or should they be removed?
>>>>
>>>>          
>>> I compile test mingw32 very often, it's part of my build test setup.
>>> If the build breaks, I may even fix the problem
>>>
>>>        
>> But do you do any testing with the Windows build?
>>      
> Sometime I do a boot test with Wine.
>
>    
>> Historically, even when Windows builds, it spends large periods of time not
>> actually working.  I think Stefan can confirm this.  Much of the platform
>> specific code is way behind (like the block layer) and has been for many
>> years.
>>
>> I can't remember the last time someone sent a Win32 enhancement for platform
>> code.
>>
>> Given that it's known to have a lot of issues, I would suggest that we
>> schedule Windows host support for deprecation in 0.15.  I would not
>> recommend that we remove any of the WIN32 code from the build but basically
>> stop trying to make it even build until someone steps up to really actively
>> maintain and enhance the Windows port.  I would still suggest we take
>> patches if anyone wants to submit them but we should not avoid patches that
>> are known to break win32 (unless the fix is trivial).
>>      
> The same strategy applied to all hosts would probably eventually break
> everything but Linux on x86 with KVM

I don't think that's true but I do agree that we'd lose a lot of 
features.  But if the features aren't being used by anyone and they 
consistently don't work, does it matter?

> . There have been very few patches
> for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host
> CPUs. Without Darwin or BSD host support, darwin-user and bsd-user
> will be useless. When did we get Xen patches last time before the
> recent patch set?
>    

Let's put things in perspective though.  Win32 support has been in bad 
shape for years and no one really seems to care.   It's been sorely 
behind since at least when Fabrice introduced AIO support for Linux 
without ever doing it properly in Windows.

TBH, I think dropping kqemu resulted in the last few win32 users moving 
on to something else.

> What about other uncommon and possibly already broken (or never
> finished) features, like Parallels, VVFAT or VMDK support? What about
> new features, do we know in advance that they will be actively
> maintained?
>    

We ought to separately consider features that are isolated and features 
that are invasive.  For something like VMDK or VVFAT, there's very 
little burden that the rest of the code base endures simply by the code 
existing.

Win32 seems to be a constant source of pain though.

> But I'm not completely against this. Maybe we should make a list of
> features and check which of those work. Features which don't pass are
> scheduled for deprecation or removal.
>    

Yes, I think this is exactly what we need to do.

>    
>> For instance, I know that some downstreams (like Android) depend heavily on
>> Win32 so an official statement of deprecation might cause them to push some
>> of their fixes upstream and be more active in upstream maintenance.
>>      
> We haven't received any patches from VirtualBox downstream either, but
> maybe they are still using 0.9.0, so they don't have any.
>    

VBox seems to be a lost cause.  At least the Android folks have 
expressed some willingness to work upstream.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Unmaintained QEMU builds

[Jes Sorensen]

On 08/12/10 11:17, Stefan Weil wrote:
> Am 12.08.2010 00:12, schrieb Paolo Bonzini:
> Jes has an opinion how thinks should be done, and I have a different one.
> If you read the complete history, you can see that I suggested a
> compromise (*)
> which would give the same result as Jes' suggestions. Only the steps
> to reach this result were different, and I have good reasons why I
> prefer my way to do them. Both ways require two commits, so
> there would be no difference for the community nor for the
> committers.
> 
> I did not reply to Jes' last mail because he claims to represent the
> community without accepting that others (in this case me) who are
> also part of the community might have good reason for their approach, too.
> His mail was also very impolite which is one more reason why I
> did not reply.

I gave you plenty technical reasons for doing things the right way, and
you did agree that it should go to the right place. However rather than
doing the small job it was to fix up the patch, you decided to ignore it.

It's a real shame your patch was applied the way it was. The net result
of it is that someone doing a git bisect on the tree will end up with a
broken build they have to work around. Frankly if anyone here is
impolite, it is you for trying to force in patches that breaks debugging.

Jes

Re: [Qemu-devel] Unmaintained QEMU builds

[Kevin Wolf]

Am 16.08.2010 22:42, schrieb Anthony Liguori:
> On 08/16/2010 01:51 PM, Blue Swirl wrote:
>> On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>> Historically, even when Windows builds, it spends large periods of time not
>>> actually working.  I think Stefan can confirm this.  Much of the platform
>>> specific code is way behind (like the block layer) and has been for many
>>> years.
>>>
>>> I can't remember the last time someone sent a Win32 enhancement for platform
>>> code.
>>>
>>> Given that it's known to have a lot of issues, I would suggest that we
>>> schedule Windows host support for deprecation in 0.15.  I would not
>>> recommend that we remove any of the WIN32 code from the build but basically
>>> stop trying to make it even build until someone steps up to really actively
>>> maintain and enhance the Windows port.  I would still suggest we take
>>> patches if anyone wants to submit them but we should not avoid patches that
>>> are known to break win32 (unless the fix is trivial).
>>>      
>> The same strategy applied to all hosts would probably eventually break
>> everything but Linux on x86 with KVM
> 
> I don't think that's true but I do agree that we'd lose a lot of 
> features.  But if the features aren't being used by anyone and they 
> consistently don't work, does it matter?

I know more than one user for qemu on win32. However, they are just
that: users. Maybe they could be motivated to do a build fix if things
break (just like we do right now). They probably don't care about active
development (which is what you want to require) because it seems to work
"good enough". Of course, they still get improvements that are done in
the platform independent parts and I'm sure they would be unhappy about
win32 support being dropped in future versions.

>> . There have been very few patches
>> for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host
>> CPUs. Without Darwin or BSD host support, darwin-user and bsd-user
>> will be useless. When did we get Xen patches last time before the
>> recent patch set?
>>    
> 
> Let's put things in perspective though.  Win32 support has been in bad 
> shape for years and no one really seems to care.   It's been sorely 
> behind since at least when Fabrice introduced AIO support for Linux 
> without ever doing it properly in Windows.

So what? If I were to choose between working code that is not on par
with Linux or no code at all, I think I would pick the former.

Kevin

Re: [Qemu-devel] Unmaintained QEMU builds

[Anthony Liguori]

On 08/17/2010 05:09 AM, Kevin Wolf wrote:
>>> . There have been very few patches
>>> for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host
>>> CPUs. Without Darwin or BSD host support, darwin-user and bsd-user
>>> will be useless. When did we get Xen patches last time before the
>>> recent patch set?
>>>
>>>        
>> Let's put things in perspective though.  Win32 support has been in bad
>> shape for years and no one really seems to care.   It's been sorely
>> behind since at least when Fabrice introduced AIO support for Linux
>> without ever doing it properly in Windows.
>>      
> So what? If I were to choose between working code that is not on par
> with Linux or no code at all, I think I would pick the former.
>    

As I've said a few times already, code that is useful to anyone that is 
isolated and has no impact on common code is reasonable to keep forever.

But requiring everyone to consider Windows even though noone is actively 
working on it or even testing it seems a bit silly to me.  Consider 
threading as an example.  We could drop the non threaded VNC server 
entirely if we didn't have to care about breaking Windows.

Regards,

Anthony Liguori

> Kevin
>    

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

On Mon, Aug 16, 2010 at 8:42 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 08/16/2010 01:51 PM, Blue Swirl wrote:
>>
>> On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> On 08/11/2010 11:34 AM, Blue Swirl wrote:
>>>
>>>>
>>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil<weil@mail.berlios.de>
>>>>  wrote:
>>>>
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> since several months, QEMU for Windows (and mingw32 cross builds)
>>>>> no longer builds without error.
>>>>>
>>>>>
>>>>
>>>> Not true for mingw32, it was building fine here until the latest commit.
>>>>
>>>>
>>>>
>>>>>
>>>>> I suspect that the same is true for QEMU on Darwin (lots of errors like
>>>>> darwin-user/qemu.h:149: error: cast to pointer from integer of
>>>>> different
>>>>> size),
>>>>> but I'm not sure here because I have no valid Darwin test environment.
>>>>> Maybe someone can test this.
>>>>>
>>>>> What about these environments? They have no maintainers.
>>>>> Should they be marked as unsupported? Are they still used?
>>>>> Or should they be removed?
>>>>>
>>>>>
>>>>
>>>> I compile test mingw32 very often, it's part of my build test setup.
>>>> If the build breaks, I may even fix the problem
>>>>
>>>>
>>>
>>> But do you do any testing with the Windows build?
>>>
>>
>> Sometime I do a boot test with Wine.
>>
>>
>>>
>>> Historically, even when Windows builds, it spends large periods of time
>>> not
>>> actually working.  I think Stefan can confirm this.  Much of the platform
>>> specific code is way behind (like the block layer) and has been for many
>>> years.
>>>
>>> I can't remember the last time someone sent a Win32 enhancement for
>>> platform
>>> code.
>>>
>>> Given that it's known to have a lot of issues, I would suggest that we
>>> schedule Windows host support for deprecation in 0.15.  I would not
>>> recommend that we remove any of the WIN32 code from the build but
>>> basically
>>> stop trying to make it even build until someone steps up to really
>>> actively
>>> maintain and enhance the Windows port.  I would still suggest we take
>>> patches if anyone wants to submit them but we should not avoid patches
>>> that
>>> are known to break win32 (unless the fix is trivial).
>>>
>>
>> The same strategy applied to all hosts would probably eventually break
>> everything but Linux on x86 with KVM
>
> I don't think that's true but I do agree that we'd lose a lot of features.
>  But if the features aren't being used by anyone and they consistently don't
> work, does it matter?

No, but semi-actively breaking things that work now is different from
removing obsolete or never to be finished features.

>> . There have been very few patches
>> for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host
>> CPUs. Without Darwin or BSD host support, darwin-user and bsd-user
>> will be useless. When did we get Xen patches last time before the
>> recent patch set?
>>
>
> Let's put things in perspective though.  Win32 support has been in bad shape
> for years and no one really seems to care.   It's been sorely behind since
> at least when Fabrice introduced AIO support for Linux without ever doing it
> properly in Windows.

If Paolo's Win32 threads get merged, would there be other reasons
against continuing Win32 support?

> TBH, I think dropping kqemu resulted in the last few win32 users moving on
> to something else.

This would also apply to all x86 operating systems without KVM, like
*BSD, *Solaris and Darwin/x86 and it would also mean that TCG is
useless on x86. But nobody has stepped up as kqemu maintainer, which
supports your argument.

>> What about other uncommon and possibly already broken (or never
>> finished) features, like Parallels, VVFAT or VMDK support? What about
>> new features, do we know in advance that they will be actively
>> maintained?
>>
>
> We ought to separately consider features that are isolated and features that
> are invasive.  For something like VMDK or VVFAT, there's very little burden
> that the rest of the code base endures simply by the code existing.

I haven't ever used them. Do they even work?

> Win32 seems to be a constant source of pain though.

Similar pains come from any portability to non-Linux OS (or older GCCs
that don't support threads), although smaller.

>> But I'm not completely against this. Maybe we should make a list of
>> features and check which of those work. Features which don't pass are
>> scheduled for deprecation or removal.
>>
>
> Yes, I think this is exactly what we need to do.

Even better would be to check all features with for example autotest.
Automated testing would also benefit from narrowed feature set.

At least major features should have a named maintainer as well.

If nonfunctional features were also removed, QEMU would be feature
complete and bug-free so we could release a 1.0 version. ;-)

Re: [Qemu-devel] Unmaintained QEMU builds

[malc]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2220 bytes --]

On Tue, 17 Aug 2010, Blue Swirl wrote:

> On Mon, Aug 16, 2010 at 8:42 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > On 08/16/2010 01:51 PM, Blue Swirl wrote:
> >>
> >> On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori<anthony@codemonkey.ws>
> >>  wrote:
> >>
> >>>
> >>> On 08/11/2010 11:34 AM, Blue Swirl wrote:
> >>>
> >>>>
> >>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil<weil@mail.berlios.de>
> >>>>  wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> Hi,
> >>>>>

[..snip..]

> 
> > TBH, I think dropping kqemu resulted in the last few win32 users moving on
> > to something else.
> 
> This would also apply to all x86 operating systems without KVM, like
> *BSD, *Solaris and Darwin/x86 and it would also mean that TCG is
> useless on x86. But nobody has stepped up as kqemu maintainer, which
> supports your argument.
>
> 
> >> What about other uncommon and possibly already broken (or never
> >> finished) features, like Parallels, VVFAT or VMDK support? What about
> >> new features, do we know in advance that they will be actively
> >> maintained?
> >>
> >
> > We ought to separately consider features that are isolated and features that
> > are invasive.  For something like VMDK or VVFAT, there's very little burden
> > that the rest of the code base endures simply by the code existing.
> 
> I haven't ever used them. Do they even work?

VVFAT r/o does work and is useful (at least for me).
 
> > Win32 seems to be a constant source of pain though.
> 
> Similar pains come from any portability to non-Linux OS (or older GCCs
> that don't support threads), although smaller.
> 
> >> But I'm not completely against this. Maybe we should make a list of
> >> features and check which of those work. Features which don't pass are
> >> scheduled for deprecation or removal.
> >>
> >
> > Yes, I think this is exactly what we need to do.
> 
> Even better would be to check all features with for example autotest.
> Automated testing would also benefit from narrowed feature set.
> 
> At least major features should have a named maintainer as well.
> 
> If nonfunctional features were also removed, QEMU would be feature
> complete and bug-free so we could release a 1.0 version. ;-)
> 

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Unmaintained QEMU builds

[Anthony Liguori]

On 08/17/2010 01:38 PM, Blue Swirl wrote:
>>   But if the features aren't being used by anyone and they consistently don't
>> work, does it matter?
>>      
> No, but semi-actively breaking things that work now is different from
> removing obsolete or never to be finished features.
>    

I think my point is that Win32 is a "never to be finished feature".

Every time I've ever tried to use it, it's a short period of time before 
it seg faults.  I have a hard time believing that anyone is using it 
seriously.

>>> . There have been very few patches
>>> for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host
>>> CPUs. Without Darwin or BSD host support, darwin-user and bsd-user
>>> will be useless. When did we get Xen patches last time before the
>>> recent patch set?
>>>
>>>        
>> Let's put things in perspective though.  Win32 support has been in bad shape
>> for years and no one really seems to care.   It's been sorely behind since
>> at least when Fabrice introduced AIO support for Linux without ever doing it
>> properly in Windows.
>>      
> If Paolo's Win32 threads get merged, would there be other reasons
> against continuing Win32 support?
>    

I think a better question would be, should we even bother with thread 
wrappers?  If we drop win32 support, we can just assume pthreads and 
avoid a layer of indirection.

>> TBH, I think dropping kqemu resulted in the last few win32 users moving on
>> to something else.
>>      
> This would also apply to all x86 operating systems without KVM, like
> *BSD, *Solaris and Darwin/x86 and it would also mean that TCG is
> useless on x86. But nobody has stepped up as kqemu maintainer, which
> supports your argument.
>    

I disagree.  There are quite a lot more patches and features written for 
these systems than Win32.  With the exception of Darwin, at least the 
other Unices are close enough to Linux that the work to support them is 
relatively small.


>> We ought to separately consider features that are isolated and features that
>> are invasive.  For something like VMDK or VVFAT, there's very little burden
>> that the rest of the code base endures simply by the code existing.
>>      
> I haven't ever used them. Do they even work?
>    

Yes.  vmdk gets a reasonable amount of attention because of it's 
usefulness in qemu-img.  vvfat is black magic but it works reasonably 
well in read-only mode.  When it breaks, people complain quickly.

>> Win32 seems to be a constant source of pain though.
>>      
> Similar pains come from any portability to non-Linux OS (or older GCCs
> that don't support threads), although smaller.
>    

Yes.  Much, much smaller pains.

>>> But I'm not completely against this. Maybe we should make a list of
>>> features and check which of those work. Features which don't pass are
>>> scheduled for deprecation or removal.
>>>
>>>        
>> Yes, I think this is exactly what we need to do.
>>      
> Even better would be to check all features with for example autotest.
> Automated testing would also benefit from narrowed feature set.
>
> At least major features should have a named maintainer as well.
>    

Yes.  I think we have a lot of dump-and-run features in QEMU whereas 
someone writes the patches to implement something and then disappears.  
Often time, the feature is not generally useful so the code just rots.  
I think an awful lot of the PPC boards and devices also fall into this 
category.

Considering that we're well over half a million lines of code today, I 
think we would do ourselves a favor by dropping some of the dead 
features we're carrying.

Regards,

Anthony Liguori

> If nonfunctional features were also removed, QEMU would be feature
> complete and bug-free so we could release a 1.0 version. ;-)
>    

[Qemu-devel] Re: Unmaintained QEMU builds

[Paolo Bonzini]

On 08/17/2010 09:56 PM, Anthony Liguori wrote:
>> If Paolo's Win32 threads get merged, would there be other reasons
>> against continuing Win32 support?
>
> I think a better question would be, should we even bother with thread
> wrappers? If we drop win32 support, we can just assume pthreads and
> avoid a layer of indirection.

Yes, we would.  qemu_thread_create ensures the newly-created thread 
won't receive any signals, for example.

Some day the wrappers could even start using futexes directly if there 
were a reason to do so.

> I disagree. There are quite a lot more patches and features written for
> these systems than Win32. With the exception of Darwin, at least the
> other Unices are close enough to Linux that the work to support them is
> relatively small.

Darwin is as close to Linux as FreeBSD is (and very close to FreeBSD, in 
turn).

> Considering that we're well over half a million lines of code today, I
> think we would do ourselves a favor by dropping some of the dead
> features we're carrying.

I agree, for example savevm/loadvm support for embedded boards is likely 
one of these features.  Right now I see no reason to declare Win32 a 
failure, though this may change in the future.

Paolo

Re: [Qemu-devel] Unmaintained QEMU builds

[Alexander Graf]

On 17.08.2010, at 21:56, Anthony Liguori wrote:

> On 08/17/2010 01:38 PM, Blue Swirl wrote:
>>>  But if the features aren't being used by anyone and they consistently don't
>>> work, does it matter?
>>>     
>> No, but semi-actively breaking things that work now is different from
>> removing obsolete or never to be finished features.
>>   
> 
> I think my point is that Win32 is a "never to be finished feature".
> 
> Every time I've ever tried to use it, it's a short period of time before it seg faults.  I have a hard time believing that anyone is using it seriously.

I'm fairly sure people out there use it for arm development. Not sure for what else though.

> 
>>>> . There have been very few patches
>>>> for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host
>>>> CPUs. Without Darwin or BSD host support, darwin-user and bsd-user
>>>> will be useless. When did we get Xen patches last time before the
>>>> recent patch set?
>>>> 
>>>>       
>>> Let's put things in perspective though.  Win32 support has been in bad shape
>>> for years and no one really seems to care.   It's been sorely behind since
>>> at least when Fabrice introduced AIO support for Linux without ever doing it
>>> properly in Windows.
>>>     
>> If Paolo's Win32 threads get merged, would there be other reasons
>> against continuing Win32 support?
>>   
> 
> I think a better question would be, should we even bother with thread wrappers?  If we drop win32 support, we can just assume pthreads and avoid a layer of indirection.

The current threading code is also broken on osx and last time I talked to paolo, his patch should also fix things for osx. So in the end it doesn't seem like a bad idea to support win32 - it's feature set is about the least common dominator between all OSs we support.

> Yes.  I think we have a lot of dump-and-run features in QEMU whereas someone writes the patches to implement something and then disappears.  Often time, the feature is not generally useful so the code just rots.  I think an awful lot of the PPC boards and devices also fall into this category.

The sad story behind the PPC stuff is that the maintainer vanished and nobody stepped up with enough expertise and spare time to fill in on this role. I can't possibly maintain KVM on PPC and Qemu PPC at the same time :(.

> Considering that we're well over half a million lines of code today, I think we would do ourselves a favor by dropping some of the dead features we're carrying.

I think we should just make the feature matrix more flexible. I for example don't care about migration on PPC (yet). So why bother thinking about it when we don't have to? As long as our abstraction layers are good, we can just introduce stubs for stuff that doesn't have to work.

And wrt vnc and threading, I'm fully in for deprecating the non-threaded version. Platforms that don't work with threading get no VNC server.


Alex

Re: [Qemu-devel] Unmaintained QEMU builds

[Andreas Färber]

Am 17.08.2010 um 21:56 schrieb Anthony Liguori:

> I think my point is that Win32 is a "never to be finished feature".
>
> Every time I've ever tried to use it, it's a short period of time  
> before it seg faults.  I have a hard time believing that anyone is  
> using it seriously.

No "serious" Windows user will consider QEMU a viable alternative to  
the free-as-in-beer VMware as long as it doesn't provide a neat  
graphical user interface which is on par for stuff like changing the  
virtual CD (i.e., avoiding the monitor console) or configuring things.

Slightly similar lately on Mac OS X x86 with VirtualBox as semi-free  
virtualization solution. Unfortunately the Q project made the bad move  
of importing a CVS snapshot of QEMU into their SVN, so you could no  
longer properly work against upstream.

Maybe it's time to rethink the relation between QEMU and its  
frontends / management tools? If we want to compete with the  
commercial products (sic), we might agree on some "official" frontend  
per GUI-centric platform, with a Git-based repository (like qemu- 
kvm.git) and synchronized releases that may call themselves "QEMU",  
linked from qemu.org, rather than having a variety of (outdated) Q*  
frontends per platform of which most are nothing more than a  
configuration window to spawn the regular qemu[-system-x86_64].  
Currently what QEMU can point with is richer machine and hardware  
emulation and its license; if we want more users than that, we'll need  
to deliver what users usually want the most - stability, performance  
and ease of use... and good marketing.

Regards,
Andreas

Re: [Qemu-devel] Re: Unmaintained QEMU builds

[Andreas Färber]

Am 18.08.2010 um 10:31 schrieb Paolo Bonzini:

> On 08/17/2010 09:56 PM, Anthony Liguori wrote:
>>> If Paolo's Win32 threads get merged, would there be other reasons
>>> against continuing Win32 support?
>>
>> I think a better question would be, should we even bother with thread
>> wrappers? If we drop win32 support, we can just assume pthreads and
>> avoid a layer of indirection.
>
> Yes, we would.  qemu_thread_create ensures the newly-created thread  
> won't receive any signals, for example.
>
> Some day the wrappers could even start using futexes directly if  
> there were a reason to do so.

For BeOS there once was a pthreads library project. Maybe the same  
could work for Win32, implement the pthreads API and map to  
corresponding Win32 API functions? Then QEMU could use pthreads API  
and use wrappers only where strictly necessary. In theory this sounds  
less invasive.

Andreas

Re: [Qemu-devel] Unmaintained QEMU builds

[Andreas Färber]

Am 17.08.2010 um 21:56 schrieb Anthony Liguori:

> I think we have a lot of dump-and-run features in QEMU whereas  
> someone writes the patches to implement something and then  
> disappears.  Often time, the feature is not generally useful so the  
> code just rots.  I think an awful lot of the PPC boards and devices  
> also fall into this category.
>
> Considering that we're well over half a million lines of code today,  
> I think we would do ourselves a favor by dropping some of the dead  
> features we're carrying.

The only really broken ppc sysemu should be PReP atm, no? Otherwise  
I'm just aware of some OpenBIOS bugs.

Andreas

Re: [Qemu-devel] Unmaintained QEMU builds

[Alexander Graf]

On 04.09.2010, at 16:41, Andreas Färber wrote:

> Am 17.08.2010 um 21:56 schrieb Anthony Liguori:
> 
>> I think we have a lot of dump-and-run features in QEMU whereas someone writes the patches to implement something and then disappears.  Often time, the feature is not generally useful so the code just rots.  I think an awful lot of the PPC boards and devices also fall into this category.
>> 
>> Considering that we're well over half a million lines of code today, I think we would do ourselves a favor by dropping some of the dead features we're carrying.
> 
> The only really broken ppc sysemu should be PReP atm, no? Otherwise I'm just aware of some OpenBIOS bugs.

Qemu currently tries to potentially emulate every CPU flavor that ever existed in the world. I have no idea if the original 601 implementation still works. Or 603. Not to speak of the halfway-implemented BookE CPUs. I'm also fairly sure that no emulated 64 bit CPU but the G5 work.

I think the right thing to do for PPC would be to focus on a subset of CPUs we care about and make sure those work in combination.

Also, the board emulation is ... eh ... suboptimal. The code is weirdly structured and I've already squashed a lot of bugs in there to make it barely work with Linux, but I have no idea about other OSs.

The thing we _really_ should do there would be a from-scratch implementation of a U2 (32-bit) and a U3/U4 (64-bit) board and just forget about the old stuff. The big thing is that it costs time to do that and requires documentation, which all except for the U4 lack. I'm also fairly sure I won't get to it anytime soon :).


Alex

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/04/2010 04:56 PM, Andreas Färber wrote:
>
> Maybe it's time to rethink the relation between QEMU and its frontends 
> / management tools? If we want to compete with the commercial products 
> (sic), we might agree on some "official" frontend per GUI-centric 
> platform, with a Git-based repository (like qemu-kvm.git) and 
> synchronized releases that may call themselves "QEMU", linked from 
> qemu.org, rather than having a variety of (outdated) Q* frontends per 
> platform of which most are nothing more than a configuration window to 
> spawn the regular qemu[-system-x86_64]. 

There is also virt-manager which is quite rich at this time.

> Currently what QEMU can point with is richer machine and hardware 
> emulation and its license; if we want more users than that, we'll need 
> to deliver what users usually want the most - stability, performance 
> and ease of use... and good marketing.

They may as well be merged into qemu.git directly, so long as:

- the GUI has its own maintainer
- the prepackaged GUI doesn't get access to internal APIs, compared to 
external tools

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

On Sun, Sep 5, 2010 at 11:19 AM, Avi Kivity <avi@redhat.com> wrote:
>  On 09/04/2010 04:56 PM, Andreas Färber wrote:
>>
>> Maybe it's time to rethink the relation between QEMU and its frontends /
>> management tools? If we want to compete with the commercial products (sic),
>> we might agree on some "official" frontend per GUI-centric platform, with a
>> Git-based repository (like qemu-kvm.git) and synchronized releases that may
>> call themselves "QEMU", linked from qemu.org, rather than having a variety
>> of (outdated) Q* frontends per platform of which most are nothing more than
>> a configuration window to spawn the regular qemu[-system-x86_64].
>
> There is also virt-manager which is quite rich at this time.
>
>> Currently what QEMU can point with is richer machine and hardware
>> emulation and its license; if we want more users than that, we'll need to
>> deliver what users usually want the most - stability, performance and ease
>> of use... and good marketing.
>
> They may as well be merged into qemu.git directly, so long as:
>
> - the GUI has its own maintainer
> - the prepackaged GUI doesn't get access to internal APIs, compared to
> external tools

Easy to use GUI and integration to host system are important, but
performance is also a big problem. QEMU/TCG can't compete with
alternatives that use proprietary kernel modules. Someone should
recreate kqemu by using KVM compatible interfaces.

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/05/2010 05:10 PM, Blue Swirl wrote:
> Easy to use GUI and integration to host system are important, but
> performance is also a big problem. QEMU/TCG can't compete with
> alternatives that use proprietary kernel modules. Someone should
> recreate kqemu by using KVM compatible interfaces.

If someone is really willing to invest the effort to do that cleanly, I 
am willing to merge it into kvm.  That would allow reuse of the mmu and 
some other logic that got a lot of effort in kvm.

However, I doubt it is worth the effort, if anyone is interested in 
performance then they'd get a cpu that supports virtualization.

That leaves non-Linux.  Can qemu really compete there for x86-on-x86?  I 
doubt it.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

On Sun, Sep 5, 2010 at 2:17 PM, Avi Kivity <avi@redhat.com> wrote:
>  On 09/05/2010 05:10 PM, Blue Swirl wrote:
>>
>> Easy to use GUI and integration to host system are important, but
>> performance is also a big problem. QEMU/TCG can't compete with
>> alternatives that use proprietary kernel modules. Someone should
>> recreate kqemu by using KVM compatible interfaces.
>
> If someone is really willing to invest the effort to do that cleanly, I am
> willing to merge it into kvm.  That would allow reuse of the mmu and some
> other logic that got a lot of effort in kvm.
>
> However, I doubt it is worth the effort, if anyone is interested in
> performance then they'd get a cpu that supports virtualization.
>
> That leaves non-Linux.  Can qemu really compete there for x86-on-x86?  I
> doubt it.

Someone could also make a KVM compatible module for non-Linux hosts
with virtualization capable CPUs. Wouldn't that solve most performance
problems?

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/05/2010 05:40 PM, Blue Swirl wrote:
> On Sun, Sep 5, 2010 at 2:17 PM, Avi Kivity<avi@redhat.com>  wrote:
>>   On 09/05/2010 05:10 PM, Blue Swirl wrote:
>>> Easy to use GUI and integration to host system are important, but
>>> performance is also a big problem. QEMU/TCG can't compete with
>>> alternatives that use proprietary kernel modules. Someone should
>>> recreate kqemu by using KVM compatible interfaces.
>> If someone is really willing to invest the effort to do that cleanly, I am
>> willing to merge it into kvm.  That would allow reuse of the mmu and some
>> other logic that got a lot of effort in kvm.
>>
>> However, I doubt it is worth the effort, if anyone is interested in
>> performance then they'd get a cpu that supports virtualization.
>>
>> That leaves non-Linux.  Can qemu really compete there for x86-on-x86?  I
>> doubt it.
> Someone could also make a KVM compatible module for non-Linux hosts
> with virtualization capable CPUs.

Someone actually did port kvm-17 or thereabouts to Windows.

> Wouldn't that solve most performance
> problems?

It would.  What I doubt is that the qemu community can produce a GUI 
that rivals with the commercial virtualization GUIs available for Windows.

On Linux we have the advantages of being open source and of being 
integrated with the host native virtualization capabilities.  On 
Windows/Apple the first advantage isn't so important, and the second one 
doesn't exist.  So if qemu were to compete in those markets, it wouldn't 
have any advantages, but many disadvantages (foremost, being way behind 
on the GUI front).

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Unmaintained QEMU builds

[Andreas Färber]

Am 05.09.2010 um 13:19 schrieb Avi Kivity:

> On 09/04/2010 04:56 PM, Andreas Färber wrote:
>>
>> Maybe it's time to rethink the relation between QEMU and its  
>> frontends / management tools? If we want to compete with the  
>> commercial products (sic), we might agree on some "official"  
>> frontend per GUI-centric platform, with a Git-based repository  
>> (like qemu-kvm.git) and synchronized releases that may call  
>> themselves "QEMU", linked from qemu.org, rather than having a  
>> variety of (outdated) Q* frontends per platform of which most are  
>> nothing more than a configuration window to spawn the regular qemu[- 
>> system-x86_64].
>
> There is also virt-manager which is quite rich at this time.

Seems I didn't get the point across too well: Standard users on  
Windows-PC and Mac expect a solution to their needs, not a forest of  
well-designed libraries and tools with .tgz downloads. QEMU has no  
such product identity, and there's no prominent binary download link  
for Win/Mac on the qemu.org frontpage.

virt-manager is neither prominently advertised there either, nor does  
it have a Windows download.
(Fwiw while it's certainly nice on Linux and to some limited degree on  
Solaris (ancient fork apparently), I wouldn't exactly describe the  
virt-install versions I've seen as "rich"... and setting up the VM is  
somewhat a prerequisite to using virt-manager's indeed nice features.  
Fedora's default security policies on top don't exactly make it easy  
to try out .isos or downloaded disk images with virt-manager, its  
German translation had a severe contentual error in the VM's menu and  
a felt 80% of the BRC bug reports get ignored and closed by a bot  
anyway, but that's another topic.)
But sure, on Linux there's a plethora of simplistic Q* frontends, too.  
(n.b., virt-manager didn't match that regex ;)

Choice and diversity isn't wrong per se, just the comparison of the  
available options on the two given platforms has shown not to make  
QEMU a common choice. Whining about lack of bugfix contributions is  
unlikely going to change that imo.

As a baby step, is there any chance of publishing an automatic nightly  
Windows (cross-)build as a .zip file on qemu.org? That might give more  
users a chance of detecting runtime faults during the development cycle.

Andreas

>> Currently what QEMU can point with is richer machine and hardware  
>> emulation and its license; if we want more users than that, we'll  
>> need to deliver what users usually want the most - stability,  
>> performance and ease of use... and good marketing.
>
> They may as well be merged into qemu.git directly, so long as:
>
> - the GUI has its own maintainer
> - the prepackaged GUI doesn't get access to internal APIs, compared  
> to external tools
>
> -- 
> error compiling committee.c: too many arguments to function
>

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/05/2010 06:01 PM, Andreas Färber wrote:
> Am 05.09.2010 um 13:19 schrieb Avi Kivity:
>
>> On 09/04/2010 04:56 PM, Andreas Färber wrote:
>>>
>>> Maybe it's time to rethink the relation between QEMU and its 
>>> frontends / management tools? If we want to compete with the 
>>> commercial products (sic), we might agree on some "official" 
>>> frontend per GUI-centric platform, with a Git-based repository (like 
>>> qemu-kvm.git) and synchronized releases that may call themselves 
>>> "QEMU", linked from qemu.org, rather than having a variety of 
>>> (outdated) Q* frontends per platform of which most are nothing more 
>>> than a configuration window to spawn the regular qemu[-system-x86_64].
>>
>> There is also virt-manager which is quite rich at this time.
>
> Seems I didn't get the point across too well: Standard users on 
> Windows-PC and Mac expect a solution to their needs, not a forest of 
> well-designed libraries and tools with .tgz downloads. QEMU has no 
> such product identity, and there's no prominent binary download link 
> for Win/Mac on the qemu.org frontpage.
>
> virt-manager is neither prominently advertised there either, nor does 
> it have a Windows download.

Definitely, virt-manager is not a solution for Windows/Mac.

> (Fwiw while it's certainly nice on Linux and to some limited degree on 
> Solaris (ancient fork apparently), I wouldn't exactly describe the 
> virt-install versions I've seen as "rich"... and setting up the VM is 
> somewhat a prerequisite to using virt-manager's indeed nice features. 

I believe you can install a guest through virt-manager; virt-install is 
just a shortcut.

> Fedora's default security policies on top don't exactly make it easy 
> to try out .isos or downloaded disk images with virt-manager, its 
> German translation had a severe contentual error in the VM's menu and 
> a felt 80% of the BRC bug reports get ignored and closed by a bot 
> anyway, but that's another topic.)
> But sure, on Linux there's a plethora of simplistic Q* frontends, too. 
> (n.b., virt-manager didn't match that regex ;)
>
> Choice and diversity isn't wrong per se, just the comparison of the 
> available options on the two given platforms has shown not to make 
> QEMU a common choice. Whining about lack of bugfix contributions is 
> unlikely going to change that imo.
>
> As a baby step, is there any chance of publishing an automatic nightly 
> Windows (cross-)build as a .zip file on qemu.org? That might give more 
> users a chance of detecting runtime faults during the development cycle.

That's doable and useful, yes.  But I don't really see a path towards a 
competitive full fledged bundled/native qemu GUI.  It's a huge amount of 
work, no one seems interested (or has an employer who's interested), and 
it requires talent we don't have.

It will take a sustained effort by multiple people.  Until then, Windows 
will be a second class host and we'll have to rely on external GUIs.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Unmaintained QEMU builds

[Paolo Bonzini]

On 08/18/2010 11:46 AM, Alexander Graf wrote:
>>> I think a better question would be, should we even bother with
>>> thread wrappers?  If we drop win32 support, we can just assume
>>> pthreads and avoid a layer of indirection.
>
> The current threading code is also broken on osx and last time I
> talked to paolo, his patch should also fix things for osx.

Hm, really? :)  That's news to me. :)  But maybe I don't remember some
detail.

> So in the end it doesn't seem like a bad idea to support win32 - it's
> feature set is about the least common dominator between all OSs we
> support.  [...] And wrt vnc and threading, I'm fully in for
> deprecating the non-threaded version. Platforms that don't work with
>  threading get no VNC server.

Yeah, that was my motivation for writing the Win32 wrappers (and the
io-thread too, but that's longer-term).

Paolo

[Qemu-devel] Re: Unmaintained QEMU builds

[Paolo Bonzini]

On 09/04/2010 04:03 PM, Andreas Färber wrote:
> For BeOS there once was a pthreads library project. Maybe the same could
> work for Win32, implement the pthreads API and map to corresponding
> Win32 API functions? Then QEMU could use pthreads API and use wrappers
> only where strictly necessary. In theory this sounds less invasive.

There's pthread-win32 but it requires a kernel module to support 
signals; alternatively, with some care (if you call the Win32 API 
yourself, you have to ensure signals are never delivered during API 
calls) Cygwin provides the pthreads API as well.

But both are quite heavy-weight, and implementing the subset everybody 
really cares about (thread creation/joining, mutexes, condition 
variables, plus QEMU needs one inter-thread signal) is really easy.

The main thing is what you wrote in another message: what can QEMU offer 
on Windows and Darwin that semi-free Virtual Box and proprietary VMware 
cannot?  I like to think that it can offer something, but maybe I'm 
wrong. :/

Paolo

Re: [Qemu-devel] Unmaintained QEMU builds

[Andreas Färber]

Am 05.09.2010 um 16:17 schrieb Avi Kivity:

> On 09/05/2010 05:10 PM, Blue Swirl wrote:
>> Easy to use GUI and integration to host system are important, but
>> performance is also a big problem. QEMU/TCG can't compete with
>> alternatives that use proprietary kernel modules. Someone should
>> recreate kqemu by using KVM compatible interfaces.
>
> If someone is really willing to invest the effort to do that  
> cleanly, I am willing to merge it into kvm.  That would allow reuse  
> of the mmu and some other logic that got a lot of effort in kvm.

I believe I already inquired about this when kqemu was dropped: KVM is  
GPL'ed iiuc. May we use it as a kernel extension with proprietary Mac  
OS X at all then? I thought there was some controversy on whether  
runtime-linking GPL modules to a closed-source kernel constitutes a  
GPL violation or not. (it would be news to me if Darwin/x86 was ever  
supported by kqemu)
Having kqemu running as a userland service process (?) on Windows  
seems unproblematic by comparison.
Don't know about the BSDs or how this would fit with OpenSolaris'  
CDDL. On Haiku new kernel code would probably be preferred under MIT/ 
X11 License.

In either case, I'm not aware of a clear documentation of what exactly  
is required to implement on the kernel side to replace kqemu or to  
provide a completely compatible implementation. It seems like a moving  
target.

> However, I doubt it is worth the effort, if anyone is interested in  
> performance then they'd get a cpu that supports virtualization.
>
> That leaves non-Linux.

This discussion was about non-Linux only. We can hardly call the Linux  
build unmaintained! :)

Andreas

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/05/2010 06:44 PM, Andreas Färber wrote:
> Am 05.09.2010 um 16:17 schrieb Avi Kivity:
>
>> On 09/05/2010 05:10 PM, Blue Swirl wrote:
>>> Easy to use GUI and integration to host system are important, but
>>> performance is also a big problem. QEMU/TCG can't compete with
>>> alternatives that use proprietary kernel modules. Someone should
>>> recreate kqemu by using KVM compatible interfaces.
>>
>> If someone is really willing to invest the effort to do that cleanly, 
>> I am willing to merge it into kvm.  That would allow reuse of the mmu 
>> and some other logic that got a lot of effort in kvm.
>
> I believe I already inquired about this when kqemu was dropped: KVM is 
> GPL'ed iiuc. May we use it as a kernel extension with proprietary Mac 
> OS X at all then? 

No idea.

> I thought there was some controversy on whether runtime-linking GPL 
> modules to a closed-source kernel constitutes a GPL violation or not. 
> (it would be news to me if Darwin/x86 was ever supported by kqemu)
> Having kqemu running as a userland service process (?) on Windows 
> seems unproblematic by comparison.

These things want to run in the kernel (or did you mean a kernel driver 
providing services to userland?)

> Don't know about the BSDs or how this would fit with OpenSolaris' 
> CDDL. On Haiku new kernel code would probably be preferred under 
> MIT/X11 License.
>
> In either case, I'm not aware of a clear documentation of what exactly 
> is required to implement on the kernel side to replace kqemu or to 
> provide a completely compatible implementation. It seems like a moving 
> target.

You can pick any recent snapshot and implement its interface.  We don't 
force to upgrade their kernel as we go along.

>> However, I doubt it is worth the effort, if anyone is interested in 
>> performance then they'd get a cpu that supports virtualization.
>>
>> That leaves non-Linux.
>
> This discussion was about non-Linux only. We can hardly call the Linux 
> build unmaintained! :)

Yeah - I though it diverged to whether we ship a bundled GUI or not - 
without that, performance doesn't really matter for non-Linux.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Unmaintained QEMU builds

[Anthony Liguori]

On 09/05/2010 10:10 AM, Avi Kivity wrote:
>> As a baby step, is there any chance of publishing an automatic 
>> nightly Windows (cross-)build as a .zip file on qemu.org? That might 
>> give more users a chance of detecting runtime faults during the 
>> development cycle.
>
>
> That's doable and useful, yes.

I doubt it's useful.

We don't have a massive pool of developers sitting on their hands 
waiting for something else to work on.  We don't have myriads of users 
demanding better Windows support.  Search the list, there's almost no 
one asking questions about Windows and considering that it's missing a 
ton of features and constantly broken, that strongly suggests that no 
one is actually using it.

Windows support in QEMU is an academic exercise that's only of interest 
to developers.

Regards,

Anthony Liguori

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/05/2010 06:57 PM, Anthony Liguori wrote:
> On 09/05/2010 10:10 AM, Avi Kivity wrote:
>>> As a baby step, is there any chance of publishing an automatic 
>>> nightly Windows (cross-)build as a .zip file on qemu.org? That might 
>>> give more users a chance of detecting runtime faults during the 
>>> development cycle.
>>
>>
>> That's doable and useful, yes.
>
> I doubt it's useful.
>
> We don't have a massive pool of developers sitting on their hands 
> waiting for something else to work on.  We don't have myriads of users 
> demanding better Windows support.  Search the list, there's almost no 
> one asking questions about Windows and considering that it's missing a 
> ton of features and constantly broken, that strongly suggests that no 
> one is actually using it.

Or maybe, real users don't use the git repository, so they aren't aware 
of the constant breakage.

> Windows support in QEMU is an academic exercise that's only of 
> interest to developers.

I'm perfectly fine with dropping it.  btw, there are other features in 
qemu that seem to be academic exercises - *-user for example.  What is 
it useful for?  Most open source stuff is multiplatform, and serious 
commercial work needs something faster than tcg.

I can understand cross-cpu system mode being very useful to embedded or 
kernel developers.  x-on-x is only useful with virtualization, otherwise 
the performance penalty is too great.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Unmaintained QEMU builds

[Blue Swirl]

On Sun, Sep 5, 2010 at 4:05 PM, Avi Kivity <avi@redhat.com> wrote:
>  On 09/05/2010 06:57 PM, Anthony Liguori wrote:
>>
>> On 09/05/2010 10:10 AM, Avi Kivity wrote:
>>>>
>>>> As a baby step, is there any chance of publishing an automatic nightly
>>>> Windows (cross-)build as a .zip file on qemu.org? That might give more users
>>>> a chance of detecting runtime faults during the development cycle.
>>>
>>>
>>> That's doable and useful, yes.
>>
>> I doubt it's useful.
>>
>> We don't have a massive pool of developers sitting on their hands waiting
>> for something else to work on.  We don't have myriads of users demanding
>> better Windows support.  Search the list, there's almost no one asking
>> questions about Windows and considering that it's missing a ton of features
>> and constantly broken, that strongly suggests that no one is actually using
>> it.
>
> Or maybe, real users don't use the git repository, so they aren't aware of
> the constant breakage.
>
>> Windows support in QEMU is an academic exercise that's only of interest to
>> developers.
>
> I'm perfectly fine with dropping it.  btw, there are other features in qemu
> that seem to be academic exercises - *-user for example.  What is it useful
> for?  Most open source stuff is multiplatform, and serious commercial work
> needs something faster than tcg.

*-user can be used by developers to make specific tests with TCG more
easily and faster than with system emulation. I think someone also
used it to run Wine on PPC.

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/05/2010 07:25 PM, Blue Swirl wrote:
>
>> I'm perfectly fine with dropping it.  btw, there are other features in qemu
>> that seem to be academic exercises - *-user for example.  What is it useful
>> for?  Most open source stuff is multiplatform, and serious commercial work
>> needs something faster than tcg.
> *-user can be used by developers to make specific tests with TCG more
> easily and faster than with system emulation.

Maybe we need a unit test framework instead?  Translating system calls 
is a lot of work for testing a jitter.

(of course, *-user exists, so why not use it)

> I think someone also
> used it to run Wine on PPC.

That's dead now.  And in any case, it would be too slow for production 
use of contemporary software.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Unmaintained QEMU builds

[Andreas Färber]

Am 05.09.2010 um 17:41 schrieb Paolo Bonzini:

> The main thing is what you wrote in another message: what can QEMU  
> offer on Windows and Darwin that semi-free Virtual Box and  
> proprietary VMware cannot?  I like to think that it can offer  
> something, but maybe I'm wrong. :/

On Darwin/ppc64, I'm using QEMU for emulation of ppc, sparc and less  
common x86. There's no real competitor. My management tool is bash  
though.

On Darwin/x86, VirtualBox has a foreign Qt-based UI. In terms of the  
machine's GUI itself it shouldn't be too hard to compete with some  
extensions to the Cocoa frontend (was going to look into that, QMP  
might make this less invasive).
VMware Fusion and Parallels are not free.

Never used it on Windows. I guess it's more the unique emulation  
capabilities it has to offer.

Andreas

Re: [Qemu-devel] Unmaintained QEMU builds

[malc]

On Sun, 5 Sep 2010, Avi Kivity wrote:

>  On 09/05/2010 06:57 PM, Anthony Liguori wrote:
> > On 09/05/2010 10:10 AM, Avi Kivity wrote:
> > > > As a baby step, is there any chance of publishing an automatic nightly
> > > > Windows (cross-)build as a .zip file on qemu.org? That might give more
> > > > users a chance of detecting runtime faults during the development cycle.
> > > 
> > > 
> > > That's doable and useful, yes.
> > 
> > I doubt it's useful.
> > 
> > We don't have a massive pool of developers sitting on their hands waiting
> > for something else to work on.  We don't have myriads of users demanding
> > better Windows support.  Search the list, there's almost no one asking
> > questions about Windows and considering that it's missing a ton of features
> > and constantly broken, that strongly suggests that no one is actually using
> > it.
> 
> Or maybe, real users don't use the git repository, so they aren't aware of the
> constant breakage.
> 
> > Windows support in QEMU is an academic exercise that's only of interest to
> > developers.
> 
> I'm perfectly fine with dropping it.  btw, there are other features in qemu
> that seem to be academic exercises - *-user for example.  What is it useful
> for?  Most open source stuff is multiplatform, and serious commercial work
> needs something faster than tcg.

Riiight.. Here's a story, my work duties required me to fiddled with
IP3K based board, thing is - even though their gdb patches were obviously
freely available they were hopelessly endianness confused there were
two options: a) fix it b) use linux-user to run their x86 version of gdb.

I picked b) and it worked just fine. Actually i have two stories, story
number two, since i do not have Adobe Flash but sometimes want to watch
a non-youtube video i need somehow to figure out how .swf requests the
file, giving that i didn't exactly want to learn Flash assembly and the
only decompiler was binary only, i just used it with linux-user.

> 
> I can understand cross-cpu system mode being very useful to embedded or kernel
> developers.  x-on-x is only useful with virtualization, otherwise the
> performance penalty is too great.
> 
> 

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Unmaintained QEMU builds

[Peter Maydell]

On 5 September 2010 17:05, Avi Kivity <avi@redhat.com> wrote:
> I'm perfectly fine with dropping it.  btw, there are other features in qemu
> that seem to be academic exercises - *-user for example.  What is it useful
> for?  Most open source stuff is multiplatform, and serious commercial work
> needs something faster than tcg.
>
> I can understand cross-cpu system mode being very useful to embedded or
> kernel developers.  x-on-x is only useful with virtualization, otherwise the
> performance penalty is too great.

Cross-cpu -user mode gets used in embedded development environments
like Scratchbox as a compilation environment, where it gets you a number
of advantages over -system mode:
 * much closer integration with the host filesystem etc
 * you can use a chroot with a mix of native and target-architecture binaries
(so eg bash is the fast native version, gcc is actually a cross compiler,
but target binaries built and run by autoconf also work, via binfmt_misc)
 * it's faster than full system emulation
 * you get to use all your host system's resources rather than just
   (for example) the 256MB RAM the target system supports

(There are disadvantages to doing it that way too, but I think it's a
real, common qemu use case.)

-- Peter Maydell

Re: [Qemu-devel] Unmaintained QEMU builds

[andrzej zaborowski]

On 5 September 2010 19:33, malc <av1474@comtv.ru> wrote:
> On Sun, 5 Sep 2010, Avi Kivity wrote:
>
>>  On 09/05/2010 06:57 PM, Anthony Liguori wrote:
>> > On 09/05/2010 10:10 AM, Avi Kivity wrote:
>> > > > As a baby step, is there any chance of publishing an automatic nightly
>> > > > Windows (cross-)build as a .zip file on qemu.org? That might give more
>> > > > users a chance of detecting runtime faults during the development cycle.
>> > >
>> > >
>> > > That's doable and useful, yes.
>> >
>> > I doubt it's useful.
>> >
>> > We don't have a massive pool of developers sitting on their hands waiting
>> > for something else to work on.  We don't have myriads of users demanding
>> > better Windows support.  Search the list, there's almost no one asking
>> > questions about Windows and considering that it's missing a ton of features
>> > and constantly broken, that strongly suggests that no one is actually using
>> > it.
>>
>> Or maybe, real users don't use the git repository, so they aren't aware of the
>> constant breakage.
>>
>> > Windows support in QEMU is an academic exercise that's only of interest to
>> > developers.
>>
>> I'm perfectly fine with dropping it.  btw, there are other features in qemu
>> that seem to be academic exercises - *-user for example.  What is it useful
>> for?  Most open source stuff is multiplatform, and serious commercial work
>> needs something faster than tcg.
>
> Riiight.. Here's a story, my work duties required me to fiddled with

More examples of industrial use are Nokia and Palm using OpenEmbedded
building firmware for their phones, which afaik I relies for some
parts on qemu (just some parts, so the tcg performance doesn't impact
overall performance that much).  There are many more users of OE, but
these two have products in shops near me.

Cheers

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/05/2010 08:44 PM, andrzej zaborowski wrote:
>
>>> I'm perfectly fine with dropping it.  btw, there are other features in qemu
>>> that seem to be academic exercises - *-user for example.  What is it useful
>>> for?  Most open source stuff is multiplatform, and serious commercial work
>>> needs something faster than tcg.
>> Riiight.. Here's a story, my work duties required me to fiddled with
> More examples of industrial use are Nokia and Palm using OpenEmbedded
> building firmware for their phones, which afaik I relies for some
> parts on qemu (just some parts, so the tcg performance doesn't impact
> overall performance that much).  There are many more users of OE, but
> these two have products in shops near me.

Well, both these examples are very far from the typical end user or even 
typical developer.

No doubt anything is useful for someone, given the are 6.7Gp of us on 
this planet.

Are those examples worth the effort?  I don't know, but I'm sceptical.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Unmaintained ppc features (was: Unmaintained QEMU builds)

[Andreas Färber]

Am 05.09.2010 um 12:03 schrieb Alexander Graf:

> On 04.09.2010, at 16:41, Andreas Färber wrote:
>
>> Am 17.08.2010 um 21:56 schrieb Anthony Liguori:
>>
>>> Often time, the feature is not generally useful so the code just  
>>> rots.  I think an awful lot of the PPC boards and devices also  
>>> fall into this category.
>>>
>>> Considering that we're well over half a million lines of code  
>>> today, I think we would do ourselves a favor by dropping some of  
>>> the dead features we're carrying.
>>
>> The only really broken ppc sysemu should be PReP atm, no? Otherwise  
>> I'm just aware of some OpenBIOS bugs.
>
> Qemu currently tries to potentially emulate every CPU flavor that  
> ever existed in the world.

Yeah, noticed the diversity and the hardly comprehensible macros  
during the TCG conversion.

Yet conditionalizing instructions based on CPU doesn't seem wrong when  
you notice it in the manuals, arm does it too and Paul insisted on  
contributors doing that right.

> I have no idea if the original 601 implementation still works. Or  
> 603. Not to speak of the halfway-implemented BookE CPUs. I'm also  
> fairly sure that no emulated 64 bit CPU but the G5 work.
>
> I think the right thing to do for PPC would be to focus on a subset  
> of CPUs we care about and make sure those work in combination.
>
> Also, the board emulation is ... eh ... suboptimal. The code is  
> weirdly structured and I've already squashed a lot of bugs in there  
> to make it barely work with Linux, but I have no idea about other OSs.

Haiku/ppc was not working yet, I'm tracking some ofmem issues in  
OpenBIOS.
http://permalink.gmane.org/gmane.comp.bios.openbios/3090

> The thing we _really_ should do there would be a from-scratch  
> implementation of a U2 (32-bit) and a U3/U4 (64-bit) board and just  
> forget about the old stuff.

While the PowerMacs are my main focus, I would actually be curious  
about 'old' BeBox emulation (dual 603, proprietary boot ROM; a GSoC  
suggestion) and interested in some new AIX capable machine (possibly  
reusing the now untested POWER stuff?).

And it seemed like Hollis were still using some ppcemb board at his  
new job.

Andreas

Re: [Qemu-devel] Unmaintained QEMU builds

[andrzej zaborowski]

On 5 September 2010 19:51, Avi Kivity <avi@redhat.com> wrote:
>  On 09/05/2010 08:44 PM, andrzej zaborowski wrote:
>>
>>>> I'm perfectly fine with dropping it.  btw, there are other features in
>>>> qemu
>>>> that seem to be academic exercises - *-user for example.  What is it
>>>> useful
>>>> for?  Most open source stuff is multiplatform, and serious commercial
>>>> work
>>>> needs something faster than tcg.
>>>
>>> Riiight.. Here's a story, my work duties required me to fiddled with
>>
>> More examples of industrial use are Nokia and Palm using OpenEmbedded
>> building firmware for their phones, which afaik I relies for some
>> parts on qemu (just some parts, so the tcg performance doesn't impact
>> overall performance that much).  There are many more users of OE, but
>> these two have products in shops near me.
>
> Well, both these examples are very far from the typical end user or even
> typical developer.

Some of the industrial users include all of their "app developers"
which count in big numbers.  Now I haven't installed Nokia or Palm's
SDKs but Poky's SDK (OE-based) does include qemu.  So I wouldn't be
surprised if the number of deployments is bigger than system mode
qemu.

Cheers

Re: [Qemu-devel] Unmaintained QEMU builds

[Avi Kivity]

  On 09/05/2010 08:56 PM, andrzej zaborowski wrote:
>
>> Well, both these examples are very far from the typical end user or even
>> typical developer.
> Some of the industrial users include all of their "app developers"
> which count in big numbers.  Now I haven't installed Nokia or Palm's
> SDKs but Poky's SDK (OE-based) does include qemu.  So I wouldn't be
> surprised if the number of deployments is bigger than system mode
> qemu.

Interesting.  Well, I take back my remarks on *-user.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Unmaintained QEMU builds

[Edgar E. Iglesias]

On Sun, Sep 05, 2010 at 07:56:02PM +0200, andrzej zaborowski wrote:
> On 5 September 2010 19:51, Avi Kivity <avi@redhat.com> wrote:
> >  On 09/05/2010 08:44 PM, andrzej zaborowski wrote:
> >>
> >>>> I'm perfectly fine with dropping it.  btw, there are other features in
> >>>> qemu
> >>>> that seem to be academic exercises - *-user for example.  What is it
> >>>> useful
> >>>> for?  Most open source stuff is multiplatform, and serious commercial
> >>>> work
> >>>> needs something faster than tcg.
> >>>
> >>> Riiight.. Here's a story, my work duties required me to fiddled with
> >>
> >> More examples of industrial use are Nokia and Palm using OpenEmbedded
> >> building firmware for their phones, which afaik I relies for some
> >> parts on qemu (just some parts, so the tcg performance doesn't impact
> >> overall performance that much).  There are many more users of OE, but
> >> these two have products in shops near me.
> >
> > Well, both these examples are very far from the typical end user or even
> > typical developer.
> 
> Some of the industrial users include all of their "app developers"
> which count in big numbers.  Now I haven't installed Nokia or Palm's
> SDKs but Poky's SDK (OE-based) does include qemu.  So I wouldn't be
> surprised if the number of deployments is bigger than system mode
> qemu.

I agree, removing linux-user emulation doesn't make any sense to me.

Cheers

Re: [Qemu-devel] Unmaintained QEMU builds

[Anthony Liguori]

On 09/05/2010 11:05 AM, Avi Kivity wrote:
>> We don't have a massive pool of developers sitting on their hands 
>> waiting for something else to work on.  We don't have myriads of 
>> users demanding better Windows support.  Search the list, there's 
>> almost no one asking questions about Windows and considering that 
>> it's missing a ton of features and constantly broken, that strongly 
>> suggests that no one is actually using it.
>
>
> Or maybe, real users don't use the git repository, so they aren't 
> aware of the constant breakage.

We're not talking about has been broken for 6 months.  Windows support 
has been shady in QEMU as long as I've been involved in the project 
which is pretty much as long as Windows support has existed.

IOW, the Windows port is really a "work in progress" that hasn't made 
any progress.

>> Windows support in QEMU is an academic exercise that's only of 
>> interest to developers.
>
> I'm perfectly fine with dropping it.  btw, there are other features in 
> qemu that seem to be academic exercises - *-user for example.  What is 
> it useful for?  Most open source stuff is multiplatform, and serious 
> commercial work needs something faster than tcg.

A good example of where -user is being actively used is for doing cross 
builds.

A lot of build systems have proper cross compiler support and many still 
generate special programs and expect to be able to run them.  So an 
alternative to the traditional --cross-prefix is to setup a linux-user 
based root and replace GCC/LD with cross compilers.  That let's the 
native build system be used and the lion share of the work is done with 
native code.

Regards,

Anthony Liguori

> I can understand cross-cpu system mode being very useful to embedded 
> or kernel developers.  x-on-x is only useful with virtualization, 
> otherwise the performance penalty is too great.
>

Re: [Qemu-devel] Unmaintained QEMU builds

[Anthony Liguori]

On 09/05/2010 12:51 PM, Avi Kivity wrote:
>  On 09/05/2010 08:44 PM, andrzej zaborowski wrote:
>>
>>>> I'm perfectly fine with dropping it.  btw, there are other features 
>>>> in qemu
>>>> that seem to be academic exercises - *-user for example.  What is 
>>>> it useful
>>>> for?  Most open source stuff is multiplatform, and serious 
>>>> commercial work
>>>> needs something faster than tcg.
>>> Riiight.. Here's a story, my work duties required me to fiddled with
>> More examples of industrial use are Nokia and Palm using OpenEmbedded
>> building firmware for their phones, which afaik I relies for some
>> parts on qemu (just some parts, so the tcg performance doesn't impact
>> overall performance that much).  There are many more users of OE, but
>> these two have products in shops near me.
>
> Well, both these examples are very far from the typical end user or 
> even typical developer.
>
> No doubt anything is useful for someone, given the are 6.7Gp of us on 
> this planet.
>
> Are those examples worth the effort?  I don't know, but I'm sceptical.

-linux-user really doesn't impact much common code so the effort is 
pretty low.

Regards,

Anthony Liguori

[Qemu-devel] Re: Unmaintained QEMU builds

[Paolo Bonzini]

On 09/05/2010 06:05 PM, Avi Kivity wrote:
> I'm perfectly fine with dropping it. btw, there are other features in
> qemu that seem to be academic exercises - *-user for example. What is it
> useful for? Most open source stuff is multiplatform, and serious
> commercial work needs something faster than tcg.

*-user is useful to GCC developers (and used by those who work on the 
ARM backend to run the GCC testsuite).

Paolo

Re: [Qemu-devel] Re: Unmaintained QEMU builds

[Corentin Chary]

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

On Mon, Sep 6, 2010 at 10:59 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 09/05/2010 06:05 PM, Avi Kivity wrote:
>
>> I'm perfectly fine with dropping it. btw, there are other features in
>> qemu that seem to be academic exercises - *-user for example. What is it
>> useful for? Most open source stuff is multiplatform, and serious
>> commercial work needs something faster than tcg.
>>
>
> *-user is useful to GCC developers (and used by those who work on the ARM
> backend to run the GCC testsuite).
>
> Paolo
>
>
>
Isn't that also used by scratchbox ?

-- 
Corentin Chary
http://xf.iksaif.net

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

Re: [Qemu-devel] Unmaintained QEMU builds

[Andreas Färber]

Am 05.09.2010 um 17:57 schrieb Anthony Liguori:

> On 09/05/2010 10:10 AM, Avi Kivity wrote:
>>> As a baby step, is there any chance of publishing an automatic  
>>> nightly Windows (cross-)build as a .zip file on qemu.org? That  
>>> might give more users a chance of detecting runtime faults during  
>>> the development cycle.
>>
>> That's doable and useful, yes.
>
> I doubt it's useful.
>
> [...] We don't have myriads of users demanding better Windows  
> support.  Search the list, there's almost no one asking questions  
> about Windows [...]

Right. There's some more recent posts on that QEMU forum, although  
buried beneath a pile of spam.

Anyway, it's a chicken-and-egg problem. There's not much Win32 (nor  
Win64) contributions, there's a guesstimated minor number of users.  
Many of us including myself don't really care about the platform. When  
some Windows user does show up and reports an error against QEMU  
Manager v7.0, we have no clue what QEMU exactly that is based on, how  
it was compiled and whether there may be downstream patches involved,  
so we're not of much help. Nobody that I remember ever came up with  
git-bisect results to pinpoint where/how their regression was  
introduced.

There's three ways out:

1) We drop Windows support. No Windows user has so far participated in  
the discussion. When they cry, it'll be too late, cf. kqemu.

2) They make a step towards us.
* Posting questions, thankyous, patches here (and not just about the  
forum being down, like right now;), showing their existence and interest
* Basing patches on Git master and not some oldish release tarball
* Separating unrelated changes and explaining why changes were necessary
* Expecting and responding to review feedback
* ...

3) We make a step towards them. Some trivial step might (or might not)  
raise QEMU's attractiveness and get us one or another mid-term  
contribution.
* Build && publish Win32 binaries with a cron job
* Suggest a Win32 GSoC project?
* Move some of the nice feature documentation from the Contribute Wiki  
section to the About section for better visibility
* Publish a roadmap with estimated release dates to aid downstreams,  
improve downstream/upstream communication beyond KVM
* Add more guiding Wiki contents or link & update/extend MAINTAINERS  
file: define the defacto processes (rebase against Git tree URL, cc  
<email>, link to git-format-patch/git-send-email man page) and add  
info on missing subsystems/files (e.g. linux-user, Cocoa, SDL, VNC,  
the various TCG targets) and update maintainers (many Fabrices and  
question marks)
* Spawn topic lists to reduce qemu-devel traffic? (bugs? block? sparc?)
* Embrace feature contributions of sub-perfect quality? (i.e., picking  
good stuff from bad patches - thinking of an Austrian WLAN+Win32  
patch, an Italian ppcemb patch w/debug leftovers, the Haiku/x86 host  
patch (will ping him again), ...)
* ...

Most of the latter thoughts turn out not to be Windows-specific at all.

Regards,
Andreas

Re: [Qemu-devel] Unmaintained QEMU builds

[Tristan Gingold]

On Sep 7, 2010, at 12:44 AM, Andreas Färber wrote:

> Am 05.09.2010 um 17:57 schrieb Anthony Liguori:
> 
>> On 09/05/2010 10:10 AM, Avi Kivity wrote:
>>>> As a baby step, is there any chance of publishing an automatic nightly Windows (cross-)build as a .zip file on qemu.org? That might give more users a chance of detecting runtime faults during the development cycle.
>>> 
>>> That's doable and useful, yes.
>> 
>> I doubt it's useful.
>> 
>> [...] We don't have myriads of users demanding better Windows support.  Search the list, there's almost no one asking questions about Windows [...]
> 
> Right. There's some more recent posts on that QEMU forum, although buried beneath a pile of spam.
> 
> Anyway, it's a chicken-and-egg problem. There's not much Win32 (nor Win64) contributions, there's a guesstimated minor number of users. Many of us including myself don't really care about the platform. When some Windows user does show up and reports an error against QEMU Manager v7.0, we have no clue what QEMU exactly that is based on, how it was compiled and whether there may be downstream patches involved, so we're not of much help. Nobody that I remember ever came up with git-bisect results to pinpoint where/how their regression was introduced.

We use qemu on windows.  But in fact all our work is currently based on qemu 0.11.

But we don't use qemu like most of you: we mostly care about ppc, we don't care about the bios (we directly run our executables) and
we run without vga card (serial line is fine for us).  This configuration works (or maybe worked) pretty well.

When qemu 0.13 will be available, we will try to port our patchset on both 0.13 and head.  We also plan to submit some of our patches.
Then we will try to more closely follow the development.

Tristan.

[Qemu-devel] Re: Unmaintained QEMU builds

[Paolo Bonzini]

On 09/07/2010 12:44 AM, Andreas Färber wrote:
> 1) We drop Windows support. No Windows user has so far participated in
> the discussion. When they cry, it'll be too late, cf. kqemu.

That's different.  kqemu was crippling qemu development much more than 
Win32.  kqemu littered the code with #ifdefs but, so far, problems due 
to Win32 are only opinions.

Paolo, right now not wearing a red hat

Re: [Qemu-devel] Unmaintained QEMU builds

[Alexander Graf]

On 07.09.2010, at 09:38, Tristan Gingold wrote:

> 
> On Sep 7, 2010, at 12:44 AM, Andreas Färber wrote:
> 
>> Am 05.09.2010 um 17:57 schrieb Anthony Liguori:
>> 
>>> On 09/05/2010 10:10 AM, Avi Kivity wrote:
>>>>> As a baby step, is there any chance of publishing an automatic nightly Windows (cross-)build as a .zip file on qemu.org? That might give more users a chance of detecting runtime faults during the development cycle.
>>>> 
>>>> That's doable and useful, yes.
>>> 
>>> I doubt it's useful.
>>> 
>>> [...] We don't have myriads of users demanding better Windows support.  Search the list, there's almost no one asking questions about Windows [...]
>> 
>> Right. There's some more recent posts on that QEMU forum, although buried beneath a pile of spam.
>> 
>> Anyway, it's a chicken-and-egg problem. There's not much Win32 (nor Win64) contributions, there's a guesstimated minor number of users. Many of us including myself don't really care about the platform. When some Windows user does show up and reports an error against QEMU Manager v7.0, we have no clue what QEMU exactly that is based on, how it was compiled and whether there may be downstream patches involved, so we're not of much help. Nobody that I remember ever came up with git-bisect results to pinpoint where/how their regression was introduced.
> 
> We use qemu on windows.  But in fact all our work is currently based on qemu 0.11.
> 
> But we don't use qemu like most of you: we mostly care about ppc, we don't care about the bios (we directly run our executables) and
> we run without vga card (serial line is fine for us).  This configuration works (or maybe worked) pretty well.

Mind if I ask what exactly you're trying to emulate there?

Alex

> When qemu 0.13 will be available, we will try to port our patchset on both 0.13 and head.  We also plan to submit some of our patches.
> Then we will try to more closely follow the development.

That sounds great.

Overall, I think all we lack is someone who feels responsible for Windows. And that person should be the maintainer and whenever something needs to be done wrt Windows, it's his field. We do the same for BSD (blue swirl) and pretty much OSX (Andreas and me). The real missing point here is someone who feels responsible.


Alex

Re: [Qemu-devel] Unmaintained QEMU builds

[Tristan Gingold]

On Sep 7, 2010, at 12:22 PM, Alexander Graf wrote:

> 
> On 07.09.2010, at 09:38, Tristan Gingold wrote:
> 
>> 
>> On Sep 7, 2010, at 12:44 AM, Andreas Färber wrote:
>> 
>>> Am 05.09.2010 um 17:57 schrieb Anthony Liguori:
>>> 
>>>> On 09/05/2010 10:10 AM, Avi Kivity wrote:
>>>>>> As a baby step, is there any chance of publishing an automatic nightly Windows (cross-)build as a .zip file on qemu.org? That might give more users a chance of detecting runtime faults during the development cycle.
>>>>> 
>>>>> That's doable and useful, yes.
>>>> 
>>>> I doubt it's useful.
>>>> 
>>>> [...] We don't have myriads of users demanding better Windows support.  Search the list, there's almost no one asking questions about Windows [...]
>>> 
>>> Right. There's some more recent posts on that QEMU forum, although buried beneath a pile of spam.
>>> 
>>> Anyway, it's a chicken-and-egg problem. There's not much Win32 (nor Win64) contributions, there's a guesstimated minor number of users. Many of us including myself don't really care about the platform. When some Windows user does show up and reports an error against QEMU Manager v7.0, we have no clue what QEMU exactly that is based on, how it was compiled and whether there may be downstream patches involved, so we're not of much help. Nobody that I remember ever came up with git-bisect results to pinpoint where/how their regression was introduced.
>> 
>> We use qemu on windows.  But in fact all our work is currently based on qemu 0.11.
>> 
>> But we don't use qemu like most of you: we mostly care about ppc, we don't care about the bios (we directly run our executables) and
>> we run without vga card (serial line is fine for us).  This configuration works (or maybe worked) pretty well.
> 
> Mind if I ask what exactly you're trying to emulate there?

Sure.  As a compiler vendor, we use qemu to do testing for our bare-board ppc compiler.
We also use qemu to run tests under vxworks 5, 6, 653 and mils.

> Alex
> 
>> When qemu 0.13 will be available, we will try to port our patchset on both 0.13 and head.  We also plan to submit some of our patches.
>> Then we will try to more closely follow the development.
> 
> That sounds great.
> 
> Overall, I think all we lack is someone who feels responsible for Windows. And that person should be the maintainer and whenever something needs to be done wrt Windows, it's his field. We do the same for BSD (blue swirl) and pretty much OSX (Andreas and me). The real missing point here is someone who feels responsible.

I see.

Tristan.