On 02/08/2011 07:30 AM, Aurelien Jarno wrote:
So the strategy is let's break everything and wait for the maintainer to
fix that? This strategy doesn't work, we have seen for example that with
the SeaBIOS switch. While it brings nice features, it has broken the
isapc machine. And it's still not fixed...
The fundamental problem is that poorly thought out features have been
committed in the past. isapc is a good example of this.
You can't just remove a chipset but leave an ISA bus implementation and
expect things to just keep working. Even the early ISA-only systems had
a chipset that firmware interfaced with.
Also this strategy doesn't scale, then the maintainers are spending
their time fixing bugs introduced because others didn't care. Resources
are not unlimited, especially for those doing that on their free time.
So are you suggesting that every half baked feature should hold up any
other future developments? I think the real problem is exactly the
opposite of what you describe. Why should we waste finite resources
keeping something like Windows support limping along?
We need to do a better job of not adding features that there is no
serious intention of every supporting in a meaningful way. I think the
recent discussion of w64 is a good example of this. I can't imagine
trying to support w64 in QEMU until someone actually makes w32 work in a
reasonable way.
I think we've fixed all that we're aware of but we probably won't find
the rest unless we enable it universally.
I agree that we are going to discover bugs, and it's normal. QEMU is
quite complex and it's not possible to test every combination. That said
we are already aware of some bugs, why not fix them, or at least try to
fix them? For example we haven't fixed the performance regression with
TCG (at least it wasn't the case two weeks ago).
If there are known issues, yes, let's fix them before enabling it.
Regards,
Anthony Liguori
