* [Qemu-devel] Unmaintained QEMU builds @ 2010-08-11 10:58 Stefan Weil [not found] ` <AANLkTik+R8MZKL8LBgPUeNeCd9nL-wp94rm0MmMVqzWT@mail.gmail.com> ` (2 more replies) 0 siblings, 3 replies; 61+ messages in thread From: Stefan Weil @ 2010-08-11 10:58 UTC (permalink / raw) To: QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
[parent not found: <AANLkTik+R8MZKL8LBgPUeNeCd9nL-wp94rm0MmMVqzWT@mail.gmail.com>]
* Fwd: [Qemu-devel] Unmaintained QEMU builds [not found] ` <AANLkTik+R8MZKL8LBgPUeNeCd9nL-wp94rm0MmMVqzWT@mail.gmail.com> @ 2010-08-11 11:10 ` Matthijs ter Woord 0 siblings, 0 replies; 61+ messages in thread From: Matthijs ter Woord @ 2010-08-11 11:10 UTC (permalink / raw) To: qemu-devel [-- 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 --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-11 10:58 [Qemu-devel] Unmaintained QEMU builds Stefan Weil [not found] ` <AANLkTik+R8MZKL8LBgPUeNeCd9nL-wp94rm0MmMVqzWT@mail.gmail.com> @ 2010-08-11 16:34 ` Blue Swirl 2010-08-11 18:18 ` Stefan Weil 2010-08-15 21:42 ` Anthony Liguori 2010-08-14 15:22 ` [Qemu-devel] Unmaintained QEMU builds Andreas Färber 2 siblings, 2 replies; 61+ messages in thread From: Blue Swirl @ 2010-08-11 16:34 UTC (permalink / raw) To: Stefan Weil; +Cc: QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-11 16:34 ` Blue Swirl @ 2010-08-11 18:18 ` Stefan Weil 2010-08-11 18:51 ` Blue Swirl 2010-08-15 21:42 ` Anthony Liguori 1 sibling, 1 reply; 61+ messages in thread From: Stefan Weil @ 2010-08-11 18:18 UTC (permalink / raw) To: Blue Swirl; +Cc: QEMU Developers 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. > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-11 18:18 ` Stefan Weil @ 2010-08-11 18:51 ` Blue Swirl 2010-08-11 19:19 ` Blue Swirl 0 siblings, 1 reply; 61+ messages in thread From: Blue Swirl @ 2010-08-11 18:51 UTC (permalink / raw) To: Stefan Weil; +Cc: QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-11 18:51 ` Blue Swirl @ 2010-08-11 19:19 ` Blue Swirl 2010-08-11 19:37 ` Stefan Weil 0 siblings, 1 reply; 61+ messages in thread From: Blue Swirl @ 2010-08-11 19:19 UTC (permalink / raw) To: Stefan Weil; +Cc: QEMU Developers [-- 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 --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-11 19:19 ` Blue Swirl @ 2010-08-11 19:37 ` Stefan Weil 2010-08-11 22:12 ` [Qemu-devel] " Paolo Bonzini 2010-08-15 9:48 ` [Qemu-devel] " Blue Swirl 0 siblings, 2 replies; 61+ messages in thread From: Stefan Weil @ 2010-08-11 19:37 UTC (permalink / raw) To: Blue Swirl; +Cc: QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-08-11 19:37 ` Stefan Weil @ 2010-08-11 22:12 ` Paolo Bonzini 2010-08-12 9:17 ` Stefan Weil 2010-08-15 9:48 ` [Qemu-devel] " Blue Swirl 1 sibling, 1 reply; 61+ messages in thread From: Paolo Bonzini @ 2010-08-11 22:12 UTC (permalink / raw) To: Stefan Weil; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-08-11 22:12 ` [Qemu-devel] " Paolo Bonzini @ 2010-08-12 9:17 ` Stefan Weil 2010-08-12 12:05 ` Paolo Bonzini 2010-08-17 8:19 ` Jes Sorensen 0 siblings, 2 replies; 61+ messages in thread From: Stefan Weil @ 2010-08-12 9:17 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-08-12 9:17 ` Stefan Weil @ 2010-08-12 12:05 ` Paolo Bonzini 2010-08-17 8:19 ` Jes Sorensen 1 sibling, 0 replies; 61+ messages in thread From: Paolo Bonzini @ 2010-08-12 12:05 UTC (permalink / raw) To: Stefan Weil; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Re: Unmaintained QEMU builds 2010-08-12 9:17 ` Stefan Weil 2010-08-12 12:05 ` Paolo Bonzini @ 2010-08-17 8:19 ` Jes Sorensen 1 sibling, 0 replies; 61+ messages in thread From: Jes Sorensen @ 2010-08-17 8:19 UTC (permalink / raw) To: Stefan Weil; +Cc: Blue Swirl, Paolo Bonzini, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-11 19:37 ` Stefan Weil 2010-08-11 22:12 ` [Qemu-devel] " Paolo Bonzini @ 2010-08-15 9:48 ` Blue Swirl 1 sibling, 0 replies; 61+ messages in thread From: Blue Swirl @ 2010-08-15 9:48 UTC (permalink / raw) To: Stefan Weil; +Cc: QEMU Developers 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 > > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-11 16:34 ` Blue Swirl 2010-08-11 18:18 ` Stefan Weil @ 2010-08-15 21:42 ` Anthony Liguori 2010-08-16 8:45 ` [Qemu-devel] " Paolo Bonzini 2010-08-16 18:51 ` [Qemu-devel] " Blue Swirl 1 sibling, 2 replies; 61+ messages in thread From: Anthony Liguori @ 2010-08-15 21:42 UTC (permalink / raw) To: Blue Swirl; +Cc: QEMU Developers 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. > > ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-08-15 21:42 ` Anthony Liguori @ 2010-08-16 8:45 ` Paolo Bonzini 2010-08-16 18:51 ` [Qemu-devel] " Blue Swirl 1 sibling, 0 replies; 61+ messages in thread From: Paolo Bonzini @ 2010-08-16 8:45 UTC (permalink / raw) To: Anthony Liguori; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-15 21:42 ` Anthony Liguori 2010-08-16 8:45 ` [Qemu-devel] " Paolo Bonzini @ 2010-08-16 18:51 ` Blue Swirl 2010-08-16 20:42 ` Anthony Liguori 1 sibling, 1 reply; 61+ messages in thread From: Blue Swirl @ 2010-08-16 18:51 UTC (permalink / raw) To: Anthony Liguori; +Cc: QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-16 18:51 ` [Qemu-devel] " Blue Swirl @ 2010-08-16 20:42 ` Anthony Liguori 2010-08-17 10:09 ` Kevin Wolf 2010-08-17 18:38 ` Blue Swirl 0 siblings, 2 replies; 61+ messages in thread From: Anthony Liguori @ 2010-08-16 20:42 UTC (permalink / raw) To: Blue Swirl; +Cc: QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-16 20:42 ` Anthony Liguori @ 2010-08-17 10:09 ` Kevin Wolf 2010-08-17 13:00 ` Anthony Liguori 2010-08-17 18:38 ` Blue Swirl 1 sibling, 1 reply; 61+ messages in thread From: Kevin Wolf @ 2010-08-17 10:09 UTC (permalink / raw) To: Anthony Liguori; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-17 10:09 ` Kevin Wolf @ 2010-08-17 13:00 ` Anthony Liguori 0 siblings, 0 replies; 61+ messages in thread From: Anthony Liguori @ 2010-08-17 13:00 UTC (permalink / raw) To: Kevin Wolf; +Cc: Blue Swirl, QEMU Developers 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 > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-16 20:42 ` Anthony Liguori 2010-08-17 10:09 ` Kevin Wolf @ 2010-08-17 18:38 ` Blue Swirl 2010-08-17 18:49 ` malc 2010-08-17 19:56 ` Anthony Liguori 1 sibling, 2 replies; 61+ messages in thread From: Blue Swirl @ 2010-08-17 18:38 UTC (permalink / raw) To: Anthony Liguori; +Cc: QEMU Developers 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. ;-) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-17 18:38 ` Blue Swirl @ 2010-08-17 18:49 ` malc 2010-08-17 19:56 ` Anthony Liguori 1 sibling, 0 replies; 61+ messages in thread From: malc @ 2010-08-17 18:49 UTC (permalink / raw) To: Blue Swirl; +Cc: QEMU Developers [-- 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-17 18:38 ` Blue Swirl 2010-08-17 18:49 ` malc @ 2010-08-17 19:56 ` Anthony Liguori 2010-08-18 8:31 ` [Qemu-devel] " Paolo Bonzini ` (3 more replies) 1 sibling, 4 replies; 61+ messages in thread From: Anthony Liguori @ 2010-08-17 19:56 UTC (permalink / raw) To: Blue Swirl; +Cc: QEMU Developers 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. ;-) > ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-08-17 19:56 ` Anthony Liguori @ 2010-08-18 8:31 ` Paolo Bonzini 2010-09-04 14:03 ` Andreas Färber 2010-08-18 9:46 ` [Qemu-devel] " Alexander Graf ` (2 subsequent siblings) 3 siblings, 1 reply; 61+ messages in thread From: Paolo Bonzini @ 2010-08-18 8:31 UTC (permalink / raw) To: Anthony Liguori; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Re: Unmaintained QEMU builds 2010-08-18 8:31 ` [Qemu-devel] " Paolo Bonzini @ 2010-09-04 14:03 ` Andreas Färber 2010-09-05 15:41 ` Paolo Bonzini 0 siblings, 1 reply; 61+ messages in thread From: Andreas Färber @ 2010-09-04 14:03 UTC (permalink / raw) To: Paolo Bonzini, Anthony Liguori; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-09-04 14:03 ` Andreas Färber @ 2010-09-05 15:41 ` Paolo Bonzini 2010-09-05 16:35 ` Andreas Färber 0 siblings, 1 reply; 61+ messages in thread From: Paolo Bonzini @ 2010-09-05 15:41 UTC (permalink / raw) To: Andreas Färber; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-09-05 15:41 ` Paolo Bonzini @ 2010-09-05 16:35 ` Andreas Färber 0 siblings, 0 replies; 61+ messages in thread From: Andreas Färber @ 2010-09-05 16:35 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-17 19:56 ` Anthony Liguori 2010-08-18 8:31 ` [Qemu-devel] " Paolo Bonzini @ 2010-08-18 9:46 ` Alexander Graf 2010-09-05 15:31 ` [Qemu-devel] " Paolo Bonzini 2010-09-04 13:56 ` [Qemu-devel] " Andreas Färber 2010-09-04 14:41 ` [Qemu-devel] " Andreas Färber 3 siblings, 1 reply; 61+ messages in thread From: Alexander Graf @ 2010-08-18 9:46 UTC (permalink / raw) To: Anthony Liguori; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-08-18 9:46 ` [Qemu-devel] " Alexander Graf @ 2010-09-05 15:31 ` Paolo Bonzini 0 siblings, 0 replies; 61+ messages in thread From: Paolo Bonzini @ 2010-09-05 15:31 UTC (permalink / raw) To: Alexander Graf; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-17 19:56 ` Anthony Liguori 2010-08-18 8:31 ` [Qemu-devel] " Paolo Bonzini 2010-08-18 9:46 ` [Qemu-devel] " Alexander Graf @ 2010-09-04 13:56 ` Andreas Färber 2010-09-05 11:19 ` Avi Kivity 2010-09-04 14:41 ` [Qemu-devel] " Andreas Färber 3 siblings, 1 reply; 61+ messages in thread From: Andreas Färber @ 2010-09-04 13:56 UTC (permalink / raw) To: Anthony Liguori; +Cc: QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-04 13:56 ` [Qemu-devel] " Andreas Färber @ 2010-09-05 11:19 ` Avi Kivity 2010-09-05 14:10 ` Blue Swirl 2010-09-05 15:01 ` Andreas Färber 0 siblings, 2 replies; 61+ messages in thread From: Avi Kivity @ 2010-09-05 11:19 UTC (permalink / raw) To: Andreas Färber; +Cc: QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 11:19 ` Avi Kivity @ 2010-09-05 14:10 ` Blue Swirl 2010-09-05 14:17 ` Avi Kivity 2010-09-05 15:01 ` Andreas Färber 1 sibling, 1 reply; 61+ messages in thread From: Blue Swirl @ 2010-09-05 14:10 UTC (permalink / raw) To: Avi Kivity; +Cc: Andreas Färber, QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 14:10 ` Blue Swirl @ 2010-09-05 14:17 ` Avi Kivity 2010-09-05 14:40 ` Blue Swirl 2010-09-05 15:44 ` Andreas Färber 0 siblings, 2 replies; 61+ messages in thread From: Avi Kivity @ 2010-09-05 14:17 UTC (permalink / raw) To: Blue Swirl; +Cc: Andreas Färber, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 14:17 ` Avi Kivity @ 2010-09-05 14:40 ` Blue Swirl 2010-09-05 14:46 ` Avi Kivity 2010-09-05 15:44 ` Andreas Färber 1 sibling, 1 reply; 61+ messages in thread From: Blue Swirl @ 2010-09-05 14:40 UTC (permalink / raw) To: Avi Kivity; +Cc: Andreas Färber, QEMU Developers 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? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 14:40 ` Blue Swirl @ 2010-09-05 14:46 ` Avi Kivity 0 siblings, 0 replies; 61+ messages in thread From: Avi Kivity @ 2010-09-05 14:46 UTC (permalink / raw) To: Blue Swirl; +Cc: Andreas Färber, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 14:17 ` Avi Kivity 2010-09-05 14:40 ` Blue Swirl @ 2010-09-05 15:44 ` Andreas Färber 2010-09-05 15:57 ` Avi Kivity 1 sibling, 1 reply; 61+ messages in thread From: Andreas Färber @ 2010-09-05 15:44 UTC (permalink / raw) To: Avi Kivity; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 15:44 ` Andreas Färber @ 2010-09-05 15:57 ` Avi Kivity 0 siblings, 0 replies; 61+ messages in thread From: Avi Kivity @ 2010-09-05 15:57 UTC (permalink / raw) To: Andreas Färber; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 11:19 ` Avi Kivity 2010-09-05 14:10 ` Blue Swirl @ 2010-09-05 15:01 ` Andreas Färber 2010-09-05 15:10 ` Avi Kivity 1 sibling, 1 reply; 61+ messages in thread From: Andreas Färber @ 2010-09-05 15:01 UTC (permalink / raw) To: Avi Kivity; +Cc: QEMU Developers 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 > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 15:01 ` Andreas Färber @ 2010-09-05 15:10 ` Avi Kivity 2010-09-05 15:57 ` Anthony Liguori 0 siblings, 1 reply; 61+ messages in thread From: Avi Kivity @ 2010-09-05 15:10 UTC (permalink / raw) To: Andreas Färber; +Cc: QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 15:10 ` Avi Kivity @ 2010-09-05 15:57 ` Anthony Liguori 2010-09-05 16:05 ` Avi Kivity 2010-09-06 22:44 ` [Qemu-devel] " Andreas Färber 0 siblings, 2 replies; 61+ messages in thread From: Anthony Liguori @ 2010-09-05 15:57 UTC (permalink / raw) To: Avi Kivity; +Cc: Andreas Färber, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 15:57 ` Anthony Liguori @ 2010-09-05 16:05 ` Avi Kivity 2010-09-05 16:25 ` Blue Swirl ` (4 more replies) 2010-09-06 22:44 ` [Qemu-devel] " Andreas Färber 1 sibling, 5 replies; 61+ messages in thread From: Avi Kivity @ 2010-09-05 16:05 UTC (permalink / raw) To: Anthony Liguori; +Cc: Andreas Färber, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 16:05 ` Avi Kivity @ 2010-09-05 16:25 ` Blue Swirl 2010-09-05 16:31 ` Avi Kivity 2010-09-05 17:33 ` malc ` (3 subsequent siblings) 4 siblings, 1 reply; 61+ messages in thread From: Blue Swirl @ 2010-09-05 16:25 UTC (permalink / raw) To: Avi Kivity; +Cc: Andreas Färber, QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 16:25 ` Blue Swirl @ 2010-09-05 16:31 ` Avi Kivity 0 siblings, 0 replies; 61+ messages in thread From: Avi Kivity @ 2010-09-05 16:31 UTC (permalink / raw) To: Blue Swirl; +Cc: r, =?UTF-8?B?QW5kcmVhcyBGw6RyYmU=?=, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 16:05 ` Avi Kivity 2010-09-05 16:25 ` Blue Swirl @ 2010-09-05 17:33 ` malc 2010-09-05 17:44 ` andrzej zaborowski 2010-09-05 17:39 ` Peter Maydell ` (2 subsequent siblings) 4 siblings, 1 reply; 61+ messages in thread From: malc @ 2010-09-05 17:33 UTC (permalink / raw) To: Avi Kivity; +Cc: Andreas Färber, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 17:33 ` malc @ 2010-09-05 17:44 ` andrzej zaborowski 2010-09-05 17:51 ` Avi Kivity 0 siblings, 1 reply; 61+ messages in thread From: andrzej zaborowski @ 2010-09-05 17:44 UTC (permalink / raw) To: malc; +Cc: Andreas Färber, Avi Kivity, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 17:44 ` andrzej zaborowski @ 2010-09-05 17:51 ` Avi Kivity 2010-09-05 17:56 ` andrzej zaborowski 2010-09-05 19:27 ` Anthony Liguori 0 siblings, 2 replies; 61+ messages in thread From: Avi Kivity @ 2010-09-05 17:51 UTC (permalink / raw) To: andrzej zaborowski; +Cc: Andreas Färber, QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 17:51 ` Avi Kivity @ 2010-09-05 17:56 ` andrzej zaborowski 2010-09-05 17:57 ` Avi Kivity 2010-09-05 19:21 ` Edgar E. Iglesias 2010-09-05 19:27 ` Anthony Liguori 1 sibling, 2 replies; 61+ messages in thread From: andrzej zaborowski @ 2010-09-05 17:56 UTC (permalink / raw) To: Avi Kivity; +Cc: Andreas Färber, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 17:56 ` andrzej zaborowski @ 2010-09-05 17:57 ` Avi Kivity 2010-09-05 19:21 ` Edgar E. Iglesias 1 sibling, 0 replies; 61+ messages in thread From: Avi Kivity @ 2010-09-05 17:57 UTC (permalink / raw) To: andrzej zaborowski; +Cc: Andreas Färber, QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 17:56 ` andrzej zaborowski 2010-09-05 17:57 ` Avi Kivity @ 2010-09-05 19:21 ` Edgar E. Iglesias 1 sibling, 0 replies; 61+ messages in thread From: Edgar E. Iglesias @ 2010-09-05 19:21 UTC (permalink / raw) To: andrzej zaborowski; +Cc: Andreas Färber, Avi Kivity, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 17:51 ` Avi Kivity 2010-09-05 17:56 ` andrzej zaborowski @ 2010-09-05 19:27 ` Anthony Liguori 1 sibling, 0 replies; 61+ messages in thread From: Anthony Liguori @ 2010-09-05 19:27 UTC (permalink / raw) To: Avi Kivity; +Cc: Andreas Färber, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 16:05 ` Avi Kivity 2010-09-05 16:25 ` Blue Swirl 2010-09-05 17:33 ` malc @ 2010-09-05 17:39 ` Peter Maydell 2010-09-05 19:25 ` Anthony Liguori 2010-09-06 8:59 ` [Qemu-devel] " Paolo Bonzini 4 siblings, 0 replies; 61+ messages in thread From: Peter Maydell @ 2010-09-05 17:39 UTC (permalink / raw) To: QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 16:05 ` Avi Kivity ` (2 preceding siblings ...) 2010-09-05 17:39 ` Peter Maydell @ 2010-09-05 19:25 ` Anthony Liguori 2010-09-06 8:59 ` [Qemu-devel] " Paolo Bonzini 4 siblings, 0 replies; 61+ messages in thread From: Anthony Liguori @ 2010-09-05 19:25 UTC (permalink / raw) To: Avi Kivity; +Cc: Andreas Färber, QEMU Developers 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. > ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-09-05 16:05 ` Avi Kivity ` (3 preceding siblings ...) 2010-09-05 19:25 ` Anthony Liguori @ 2010-09-06 8:59 ` Paolo Bonzini 2010-09-06 9:33 ` Corentin Chary 4 siblings, 1 reply; 61+ messages in thread From: Paolo Bonzini @ 2010-09-06 8:59 UTC (permalink / raw) To: Avi Kivity; +Cc: =?ISO-8859-1?Q?Andreas_F=E4?=, rber, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Re: Unmaintained QEMU builds 2010-09-06 8:59 ` [Qemu-devel] " Paolo Bonzini @ 2010-09-06 9:33 ` Corentin Chary 0 siblings, 0 replies; 61+ messages in thread From: Corentin Chary @ 2010-09-06 9:33 UTC (permalink / raw) To: Paolo Bonzini; +Cc: rber, qemu-devel [-- 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 --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-05 15:57 ` Anthony Liguori 2010-09-05 16:05 ` Avi Kivity @ 2010-09-06 22:44 ` Andreas Färber 2010-09-07 7:38 ` Tristan Gingold 2010-09-07 8:45 ` [Qemu-devel] " Paolo Bonzini 1 sibling, 2 replies; 61+ messages in thread From: Andreas Färber @ 2010-09-06 22:44 UTC (permalink / raw) To: Anthony Liguori; +Cc: Avi Kivity, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-06 22:44 ` [Qemu-devel] " Andreas Färber @ 2010-09-07 7:38 ` Tristan Gingold 2010-09-07 10:22 ` Alexander Graf 2010-09-07 8:45 ` [Qemu-devel] " Paolo Bonzini 1 sibling, 1 reply; 61+ messages in thread From: Tristan Gingold @ 2010-09-07 7:38 UTC (permalink / raw) To: Andreas Färber; +Cc: Avi Kivity, QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-07 7:38 ` Tristan Gingold @ 2010-09-07 10:22 ` Alexander Graf 2010-09-07 10:31 ` Tristan Gingold 0 siblings, 1 reply; 61+ messages in thread From: Alexander Graf @ 2010-09-07 10:22 UTC (permalink / raw) To: Tristan Gingold; +Cc: Andreas Färber, Avi Kivity, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-07 10:22 ` Alexander Graf @ 2010-09-07 10:31 ` Tristan Gingold 0 siblings, 0 replies; 61+ messages in thread From: Tristan Gingold @ 2010-09-07 10:31 UTC (permalink / raw) To: Alexander Graf; +Cc: Andreas Färber, Avi Kivity, QEMU Developers 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* [Qemu-devel] Re: Unmaintained QEMU builds 2010-09-06 22:44 ` [Qemu-devel] " Andreas Färber 2010-09-07 7:38 ` Tristan Gingold @ 2010-09-07 8:45 ` Paolo Bonzini 1 sibling, 0 replies; 61+ messages in thread From: Paolo Bonzini @ 2010-09-07 8:45 UTC (permalink / raw) To: Andreas Färber; +Cc: Avi Kivity, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-17 19:56 ` Anthony Liguori ` (2 preceding siblings ...) 2010-09-04 13:56 ` [Qemu-devel] " Andreas Färber @ 2010-09-04 14:41 ` Andreas Färber 2010-09-05 10:03 ` Alexander Graf 3 siblings, 1 reply; 61+ messages in thread From: Andreas Färber @ 2010-09-04 14:41 UTC (permalink / raw) To: Anthony Liguori; +Cc: Blue Swirl, Alexander Graf, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-09-04 14:41 ` [Qemu-devel] " Andreas Färber @ 2010-09-05 10:03 ` Alexander Graf 2010-09-05 17:54 ` [Qemu-devel] Unmaintained ppc features (was: Unmaintained QEMU builds) Andreas Färber 0 siblings, 1 reply; 61+ messages in thread From: Alexander Graf @ 2010-09-05 10:03 UTC (permalink / raw) To: Andreas Färber; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained ppc features (was: Unmaintained QEMU builds) 2010-09-05 10:03 ` Alexander Graf @ 2010-09-05 17:54 ` Andreas Färber 0 siblings, 0 replies; 61+ messages in thread From: Andreas Färber @ 2010-09-05 17:54 UTC (permalink / raw) To: Alexander Graf; +Cc: Blue Swirl, QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [Qemu-devel] Unmaintained QEMU builds 2010-08-11 10:58 [Qemu-devel] Unmaintained QEMU builds Stefan Weil [not found] ` <AANLkTik+R8MZKL8LBgPUeNeCd9nL-wp94rm0MmMVqzWT@mail.gmail.com> 2010-08-11 16:34 ` Blue Swirl @ 2010-08-14 15:22 ` Andreas Färber 2 siblings, 0 replies; 61+ messages in thread From: Andreas Färber @ 2010-08-14 15:22 UTC (permalink / raw) To: Stefan Weil; +Cc: QEMU Developers 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~2010-09-07 10:31 UTC | newest] Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-08-11 10:58 [Qemu-devel] Unmaintained QEMU builds Stefan Weil [not found] ` <AANLkTik+R8MZKL8LBgPUeNeCd9nL-wp94rm0MmMVqzWT@mail.gmail.com> 2010-08-11 11:10 ` Fwd: " Matthijs ter Woord 2010-08-11 16:34 ` Blue Swirl 2010-08-11 18:18 ` Stefan Weil 2010-08-11 18:51 ` Blue Swirl 2010-08-11 19:19 ` Blue Swirl 2010-08-11 19:37 ` Stefan Weil 2010-08-11 22:12 ` [Qemu-devel] " Paolo Bonzini 2010-08-12 9:17 ` Stefan Weil 2010-08-12 12:05 ` Paolo Bonzini 2010-08-17 8:19 ` Jes Sorensen 2010-08-15 9:48 ` [Qemu-devel] " Blue Swirl 2010-08-15 21:42 ` Anthony Liguori 2010-08-16 8:45 ` [Qemu-devel] " Paolo Bonzini 2010-08-16 18:51 ` [Qemu-devel] " Blue Swirl 2010-08-16 20:42 ` Anthony Liguori 2010-08-17 10:09 ` Kevin Wolf 2010-08-17 13:00 ` Anthony Liguori 2010-08-17 18:38 ` Blue Swirl 2010-08-17 18:49 ` malc 2010-08-17 19:56 ` Anthony Liguori 2010-08-18 8:31 ` [Qemu-devel] " Paolo Bonzini 2010-09-04 14:03 ` Andreas Färber 2010-09-05 15:41 ` Paolo Bonzini 2010-09-05 16:35 ` Andreas Färber 2010-08-18 9:46 ` [Qemu-devel] " Alexander Graf 2010-09-05 15:31 ` [Qemu-devel] " Paolo Bonzini 2010-09-04 13:56 ` [Qemu-devel] " Andreas Färber 2010-09-05 11:19 ` Avi Kivity 2010-09-05 14:10 ` Blue Swirl 2010-09-05 14:17 ` Avi Kivity 2010-09-05 14:40 ` Blue Swirl 2010-09-05 14:46 ` Avi Kivity 2010-09-05 15:44 ` Andreas Färber 2010-09-05 15:57 ` Avi Kivity 2010-09-05 15:01 ` Andreas Färber 2010-09-05 15:10 ` Avi Kivity 2010-09-05 15:57 ` Anthony Liguori 2010-09-05 16:05 ` Avi Kivity 2010-09-05 16:25 ` Blue Swirl 2010-09-05 16:31 ` Avi Kivity 2010-09-05 17:33 ` malc 2010-09-05 17:44 ` andrzej zaborowski 2010-09-05 17:51 ` Avi Kivity 2010-09-05 17:56 ` andrzej zaborowski 2010-09-05 17:57 ` Avi Kivity 2010-09-05 19:21 ` Edgar E. Iglesias 2010-09-05 19:27 ` Anthony Liguori 2010-09-05 17:39 ` Peter Maydell 2010-09-05 19:25 ` Anthony Liguori 2010-09-06 8:59 ` [Qemu-devel] " Paolo Bonzini 2010-09-06 9:33 ` Corentin Chary 2010-09-06 22:44 ` [Qemu-devel] " Andreas Färber 2010-09-07 7:38 ` Tristan Gingold 2010-09-07 10:22 ` Alexander Graf 2010-09-07 10:31 ` Tristan Gingold 2010-09-07 8:45 ` [Qemu-devel] " Paolo Bonzini 2010-09-04 14:41 ` [Qemu-devel] " Andreas Färber 2010-09-05 10:03 ` Alexander Graf 2010-09-05 17:54 ` [Qemu-devel] Unmaintained ppc features (was: Unmaintained QEMU builds) Andreas Färber 2010-08-14 15:22 ` [Qemu-devel] Unmaintained QEMU builds Andreas Färber
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.