[Qemu-devel] Re: Unmaintained QEMU builds
On 09/07/2010 12:44 AM, Andreas Färber wrote: 1) We drop Windows support. No Windows user has so far participated in the discussion. When they cry, it'll be too late, cf. kqemu. That's different. kqemu was crippling qemu development much more than Win32. kqemu littered the code with #ifdefs but, so far, problems due to Win32 are only opinions. Paolo, right now not wearing a red hat
Re: [Qemu-devel] Re: Unmaintained QEMU builds
On Mon, Sep 6, 2010 at 10:59 AM, Paolo Bonzini 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
[Qemu-devel] Re: Unmaintained QEMU builds
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
[Qemu-devel] Re: Unmaintained QEMU builds
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
[Qemu-devel] Re: Unmaintained QEMU builds
On 08/18/2010 11:46 AM, Alexander Graf wrote: I think a better question would be, should we even bother with thread wrappers? If we drop win32 support, we can just assume pthreads and avoid a layer of indirection. The current threading code is also broken on osx and last time I talked to paolo, his patch should also fix things for osx. Hm, really? :) That's news to me. :) But maybe I don't remember some detail. So in the end it doesn't seem like a bad idea to support win32 - it's feature set is about the least common dominator between all OSs we support. [...] And wrt vnc and threading, I'm fully in for deprecating the non-threaded version. Platforms that don't work with threading get no VNC server. Yeah, that was my motivation for writing the Win32 wrappers (and the io-thread too, but that's longer-term). Paolo
[Qemu-devel] Re: Unmaintained QEMU builds
On 09/04/2010 04:03 PM, Andreas Färber wrote: For BeOS there once was a pthreads library project. Maybe the same could work for Win32, implement the pthreads API and map to corresponding Win32 API functions? Then QEMU could use pthreads API and use wrappers only where strictly necessary. In theory this sounds less invasive. There's pthread-win32 but it requires a kernel module to support signals; alternatively, with some care (if you call the Win32 API yourself, you have to ensure signals are never delivered during API calls) Cygwin provides the pthreads API as well. But both are quite heavy-weight, and implementing the subset everybody really cares about (thread creation/joining, mutexes, condition variables, plus QEMU needs one inter-thread signal) is really easy. The main thing is what you wrote in another message: what can QEMU offer on Windows and Darwin that semi-free Virtual Box and proprietary VMware cannot? I like to think that it can offer something, but maybe I'm wrong. :/ Paolo
Re: [Qemu-devel] Re: Unmaintained QEMU builds
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
[Qemu-devel] Re: Unmaintained QEMU builds
On 08/17/2010 09:56 PM, Anthony Liguori wrote: If Paolo's Win32 threads get merged, would there be other reasons against continuing Win32 support? I think a better question would be, should we even bother with thread wrappers? If we drop win32 support, we can just assume pthreads and avoid a layer of indirection. Yes, we would. qemu_thread_create ensures the newly-created thread won't receive any signals, for example. Some day the wrappers could even start using futexes directly if there were a reason to do so. I disagree. There are quite a lot more patches and features written for these systems than Win32. With the exception of Darwin, at least the other Unices are close enough to Linux that the work to support them is relatively small. Darwin is as close to Linux as FreeBSD is (and very close to FreeBSD, in turn). Considering that we're well over half a million lines of code today, I think we would do ourselves a favor by dropping some of the dead features we're carrying. I agree, for example savevm/loadvm support for embedded boards is likely one of these features. Right now I see no reason to declare Win32 a failure, though this may change in the future. Paolo
Re: [Qemu-devel] Re: Unmaintained QEMU builds
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
[Qemu-devel] Re: Unmaintained QEMU builds
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
[Qemu-devel] Re: Unmaintained QEMU builds
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
[Qemu-devel] Re: Unmaintained QEMU builds
Am 12.08.2010 00:12, schrieb Paolo Bonzini: On 08/11/2010 03:37 PM, Stefan Weil wrote: With these changes, build succeeds with SDL. For example, qemu-system-sparc.exe can boot from a Sparc32 CD under Wine. Yes, that's a possible solution. You could also take these patches which I sent to qemu-devel: http://patchwork.ozlabs.org/patch/49217/ http://patchwork.ozlabs.org/patch/57532/ The latter change is already in Blue Swirl's patch. The former is for the setenv issue. Jes Sorensen asked you to make some changes, and you never replied; this is the best way to keep your patch *out* of the tree. Blue Swirl patch is suboptimal with respect to setenv, because the setenv is actually useful under Win32, but I still think it should go in---and then you can fix it in a better way if you want to follow the rules of the community. Paolo Hello Paolo, Jes has an opinion how thinks should be done, and I have a different one. If you read the complete history, you can see that I suggested a compromise (*) which would give the same result as Jes' suggestions. Only the steps to reach this result were different, and I have good reasons why I prefer my way to do them. Both ways require two commits, so there would be no difference for the community nor for the committers. I did not reply to Jes' last mail because he claims to represent the community without accepting that others (in this case me) who are also part of the community might have good reason for their approach, too. His mail was also very impolite which is one more reason why I did not reply. Regards Stefan (*) http://lists.nongnu.org/archive/html/qemu-devel/2010-07/msg00054.html
[Qemu-devel] Re: Unmaintained QEMU builds
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
