qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Unmaintained QEMU builds


From: Alexander Graf
Subject: Re: [Qemu-devel] Unmaintained QEMU builds
Date: Wed, 18 Aug 2010 11:46:52 +0200

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




reply via email to

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