qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by de


From: Blue Swirl
Subject: Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default
Date: Wed, 9 Feb 2011 19:13:59 +0200

On Tue, Feb 8, 2011 at 5:09 PM, Aurelien Jarno <address@hidden> wrote:
> Anthony Liguori a écrit :
>> On 02/08/2011 07:30 AM, Aurelien Jarno wrote:
>>> So the strategy is let's break everything and wait for the maintainer to
>>> fix that? This strategy doesn't work, we have seen for example that with
>>> the SeaBIOS switch. While it brings nice features, it has broken the
>>> isapc machine. And it's still not fixed...
>>>
>>
>> The fundamental problem is that poorly thought out features have been
>> committed in the past.  isapc is a good example of this.
>>
>> You can't just remove a chipset but leave an ISA bus implementation and
>> expect things to just keep working.  Even the early ISA-only systems had
>> a chipset that firmware interfaced with.
>>
>>> Also this strategy doesn't scale, then the maintainers are spending
>>> their time fixing bugs introduced because others didn't care. Resources
>>> are not unlimited, especially for those doing that on their free time.
>>>
>>
>> So are you suggesting that every half baked feature should hold up any
>> other future developments?  I think the real problem is exactly the
>> opposite of what you describe.  Why should we waste finite resources
>> keeping something like Windows support limping along?
>>
>> We need to do a better job of not adding features that there is no
>> serious intention of every supporting in a meaningful way.  I think the
>> recent discussion of w64 is a good example of this.  I can't imagine
>> trying to support w64 in QEMU until someone actually makes w32 work in a
>> reasonable way.
>
> Yes, we should at least leave people time to find a solution. If nobody
> comes with a solution, let's consider it deprecated.

I think win32 situation is somewhat similar (but not nearly as bad as)
to kqemu's. It was useful for some users, but there were no
maintenance and when it got in the way, it was removed because nobody
could fix it.

But I'd prefer a solution where somebody steps up as Windows
maintainer. I'm also doing regular mingw32 builds but otherwise not
much.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]