On 08/06/2009 03:08 PM, Gregory Haskins wrote:
Merging the guest first means relying on
kernel interface from an out of tree driver, which well might change
before it goes in.
ABI compatibility is already addressed/handled, so even if that is true its not
a problem.
Really the correct way to address the ABI is to publish a spec and write
both host and guest drivers to that. Unfortunately we didn't do this
with virtio.
It becomes more important when you have multiple implementations (e.g.
Windows drivers).
This series implements the guest-side drivers for accelerated IO
when running on top of the AlacrityVM hypervisor, the details of
which you can find here:
http://developer.novell.com/wiki/index.php/AlacrityVM
Since AlacrityVM is kvm based, Cc k...@vger.kernel.org.
I *can* do that, but there is nothing in these drivers that is KVM specific
(its all pure PCI and VBUS). I've already made the general announcement about
the project/ml cross posted to KVM for anyone that might be interested, but I
figure I will spare the general KVM list the details unless something
specifically pertains to, or affects, KVM. For instance, when I get to pushing
the hypervisor side, I still need to work on getting that 'xinterface' patch to
you guys. I would certainly be CC'ing k...@vger when that happens since it
modifies the KVM code.
So instead, I would just encourage anyone interested (such as yourself) to join
the alacrity list so I don't bother the KVM community unless absolutely
necessary.
It's true that vbus is a separate project (in fact even virtio is
completely separate from kvm). Still I think it would be of interest to
many kvm@ readers.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
