Re: [Qemu-devel] Unmaintained QEMU builds

[malc]

On Tue, 17 Aug 2010, Blue Swirl wrote:

> On Mon, Aug 16, 2010 at 8:42 PM, Anthony Liguori <address@hidden> wrote:
> > On 08/16/2010 01:51 PM, Blue Swirl wrote:
> >>
> >> On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori<address@hidden>
> >>  wrote:
> >>
> >>>
> >>> On 08/11/2010 11:34 AM, Blue Swirl wrote:
> >>>
> >>>>
> >>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil<address@hidden>
> >>>>  wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> Hi,
> >>>>>

[..snip..]

> 
> > 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.
>
> 
> >> What about other uncommon and possibly already broken (or never
> >> finished) features, like Parallels, VVFAT or VMDK support? What about
> >> new features, do we know in advance that they will be actively
> >> maintained?
> >>
> >
> > 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?

VVFAT r/o does work and is useful (at least for me).
 
> > 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.
> 
> >> 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.
> 
> If nonfunctional features were also removed, QEMU would be feature
> complete and bug-free so we could release a 1.0 version. ;-)
> 

-- 
mailto:address@hidden