From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45245 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OlR3R-0007M9-Ml for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:38:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OlR3O-0005mE-V4 for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:38:33 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:36898) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OlR3O-0005m9-S0 for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:38:30 -0400 Received: by qyk29 with SMTP id 29so127866qyk.4 for ; Tue, 17 Aug 2010 11:38:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C69A29F.5000606@codemonkey.ws> References: <4C62825A.6000903@mail.berlios.de> <4C685F5D.2090707@codemonkey.ws> <4C69A29F.5000606@codemonkey.ws> From: Blue Swirl Date: Tue, 17 Aug 2010 18:38:08 +0000 Message-ID: Subject: Re: [Qemu-devel] Unmaintained QEMU builds Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: QEMU Developers On Mon, Aug 16, 2010 at 8:42 PM, Anthony Liguori wr= ote: > On 08/16/2010 01:51 PM, Blue Swirl wrote: >> >> On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori >> =C2=A0wrote: >> >>> >>> On 08/11/2010 11:34 AM, Blue Swirl wrote: >>> >>>> >>>> On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weil >>>> =C2=A0wrote: >>>> >>>> >>>>> >>>>> Hi, >>>>> >>>>> since several months, QEMU for Windows (and mingw32 cross builds) >>>>> no longer builds without error. >>>>> >>>>> >>>> >>>> Not true for mingw32, it was building fine here until the latest commi= t. >>>> >>>> >>>> >>>>> >>>>> I suspect that the same is true for QEMU on Darwin (lots of errors li= ke >>>>> darwin-user/qemu.h:149: error: cast to pointer from integer of >>>>> different >>>>> size), >>>>> but I'm not sure here because I have no valid Darwin test environment= . >>>>> Maybe someone can test this. >>>>> >>>>> What about these environments? They have no maintainers. >>>>> Should they be marked as unsupported? Are they still used? >>>>> Or should they be removed? >>>>> >>>>> >>>> >>>> I compile test mingw32 very often, it's part of my build test setup. >>>> If the build breaks, I may even fix the problem >>>> >>>> >>> >>> But do you do any testing with the Windows build? >>> >> >> Sometime I do a boot test with Wine. >> >> >>> >>> Historically, even when Windows builds, it spends large periods of time >>> not >>> actually working. =C2=A0I think Stefan can confirm this. =C2=A0Much of = the platform >>> specific code is way behind (like the block layer) and has been for man= y >>> years. >>> >>> I can't remember the last time someone sent a Win32 enhancement for >>> platform >>> code. >>> >>> 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. =C2=A0I would no= t >>> recommend that we remove any of the WIN32 code from the build but >>> basically >>> stop trying to make it even build until someone steps up to really >>> actively >>> maintain and enhance the Windows port. =C2=A0I would still suggest we t= ake >>> patches if anyone wants to submit them but we should not avoid patches >>> that >>> are known to break win32 (unless the fix is trivial). >>> >> >> The same strategy applied to all hosts would probably eventually break >> everything but Linux on x86 with KVM > > I don't think that's true but I do agree that we'd lose a lot of features= . > =C2=A0But if the features aren't being used by anyone and they consistent= ly 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. >> . 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. =C2=A0Win32 support has been in b= ad shape > for years and no one really seems to care. =C2=A0 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? > TBH, I think dropping kqemu resulted in the last few win32 users moving o= n > 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 t= hat > are invasive. =C2=A0For 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? > 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. ;-)