Re: [Qemu-devel] Unmaintained QEMU builds

[Anthony Liguori]

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. ;-)
>