Carsten Otte wrote:
> I think we'll have to come up with a more modular approach later on: 
> various aspects are of interest to various architectures and/or 
> platforms. The generic kernel has CONFIG_FEATURE toggles for that.
> The portability patches are not intended to split kvm into components 
> at this stage, I believe that is something that we will have to come 
> up when actual ports are being integrated. In my optinion, a 
> reasonable next-step refinement here would be to come up with a 
> generic interrupt injection call that can inject an interrupt on any 
> architecture and platform. After userspace has adopted to use that 
> one, we can keep the old call for backward compatibility reasons in a 
> deprecated state for some time before removing it.
> For now, my goal is to seperate what is generic in a way that it is a 
> functionality that a portable user space program that uses kvm can 
> expect to work the same way on all architectures and platforms.
>

We have to be careful not to force too much portability on the code.  
After all, the instruction set is different and some of the hardware 
philosophy is different.  You will never be able to run the same guest 
on different archs, or have exactly the same virtual devices.  The 
differences are real, and the goal is not portability at any cost; it is 
to share as much as possible, but not more.

Architectures which have interrupt request lines that are edge-triggered 
or level-triggered and emulate the interrupt controller in the kernel 
can share the KVM_IRQ_LINE API in some way; architectures that don't 
will need another method.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to