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
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 multipl
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
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
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
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 theor
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 sup
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 la
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.
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 un
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 diffe
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
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/49
13 matches
Mail list logo
