On Wed, 3 Jun 2009, Bill Davidsen wrote:I was referring to your "no benefit" comment, I don't dispute the technical issues. I think the idea of moving the hypervisor into the kernel and letting xen folks do the external parts as they please.
Thomas Gleixner wrote:
Aside of the paravirt, which seems to expand through arch/x86 like aWait, let's not classify something as "no improvement" when you mean "I don't
hydra, the new patches sprinkle "if (xen_...)" all over the
place. These extra xen dependencies are no improvement, they are a
royal pain in the ... They are sticky once they got merged simply
because the hypervisor relies on them and we need to provide
compatibility for a long time.
need it."
It's not about "I don't need it.". It's about having Xen dependencies
in the code all over the place which make mainatainence harder. I have
to balance the users benefit (xen dom0 support) vs. the impact on
maintainability and the restrictions which are going to be set almost
in stone by merging it.
Let's stick to technical issues, and not deny that there are a number of users
who really will have expanded capability. The technical points are valid, but
as a former and probable future xen (CentOS) user, so are the benefits.
Refusing random "if (xen...)" dependencies is a purely technical
decision. I have said more than once that I'm not against merging dom0
in general, I'm just frightened by the technical impact of a defacto
ABI which we swallow with it.
We have enough problems with real silicon and BIOS/ACPI already, why
should we add artifical and _avoidable_ virtual silicon horror ?