That is a very different situation from the AlacrityVM patches, which:Care to explain the 'breakage' and why KVM is more special in this regard
- Are a pure software concept and any compatibility mismatch is
self-inflicted. The patches are in fact breaking the ABI to KVM
intentionally (for better or worse).
than other parts of the kernel (where we don't keep any such requirements)?
Truth to be told KVM is just another driver/subsystem and Gregory's changes
are only 4KLOC of clean and easily maintainable code..
I certainly missed the time when KVM became officially part of core ABI..
Overlap and forking can still be done in special circumstances, when a projectHow it is different from any past forks?
splits and a hostile fork is inevitable due to prolongued and irreconcilable
differences between the parties and if there's no strong technical advantage
on either side. I havent seen evidence of this yet though: Gregory claims that
he wants to 'work with the community' and the KVM guys seem to agree violently
that performance can be improved - and are doing so (and are asking Gregory to
take part in that effort).
The odium of proving that the existing framework is sufficient was always on
original authors or current maintainers.
KVM guys were offered assistance from Gregory and had few months to prove that
they can get the same kind of performance using existing architecture and they
DID NOT do it.
Then please try harder. Gregory posted his initial patches in August,
it is December now and we only see artificial road-blocks instead of code
from KVM folks.