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: Anthony Liguori
Subject: Re: [Qemu-devel] Unmaintained QEMU builds
Date: Mon, 16 Aug 2010 15:42:07 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

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,

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 commit.


I suspect that the same is true for QEMU on Darwin (lots of errors like
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.  I think Stefan can confirm this.  Much of the platform
specific code is way behind (like the block layer) and has been for many
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.  I would not
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.  I would still suggest we take
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. But if the features aren't being used by anyone and they consistently don't work, does it matter?

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

TBH, I think dropping kqemu resulted in the last few win32 users moving on to something else.

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.

Win32 seems to be a constant source of pain though.

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.

For instance, I know that some downstreams (like Android) depend heavily on
Win32 so an official statement of deprecation might cause them to push some
of their fixes upstream and be more active in upstream maintenance.
We haven't received any patches from VirtualBox downstream either, but
maybe they are still using 0.9.0, so they don't have any.

VBox seems to be a lost cause. At least the Android folks have expressed some willingness to work upstream.

Regards,

Anthony Liguori




reply via email to

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