Re: portability layer?

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Hollis Blanchard wrote:
>> No, I'm saying that some #ifdeffery in both libkvm and the ioctl 
>> interface is unavoidable.
>>     
>
> If by #ifdeffery you mean having per-architecture definitions of
> structures like kvm_regs, absolutely. If you mean literal #ifdefs in the
> middle a header file, I believe that can and should be avoided.
>
>   

If it can be avoided I'm all for it.

>> Right now this is handled by qemu, which means our higher level tools 
>> are _already_ nonportable.
>>     
>
> Yes, but not *all* the higher level tools are. At some point you have a
> common interface, and at this point I think I've answered my own
> question: the qemu monitor connection is the portable interface.
>
> That means everything layered above qemu, such as libvirt and thus
> virt-manager, should work on all architectures +/- without changes.
> Lower-level software, such as GDB, would need per-architecture support.
>
>   

Ah, _those_ higher layer tools.

Each of these interfaces needs to be stabilized for different reasons:

- the kernel ABI allows the kernel and userspace to be upgraded 
independently
- libkvm is mainly for when we've merged all our changes into mainline 
qemu, and for the theoretical second user
- the qemu monitor is for the higher level tools

Note that the qemu monitor (and commandline) interface is under the 
control of the qemu maintainers, not us.  So far it has been steadily 
improving.

>> [I have a feeling we're talking a little past each other, probably due 
>> to me not knowing ppc at any level of detail.  No doubt things will 
>> become clearer when the code arrives]
>>     
>
> I don't have any code for you, but you will be the first to know when I
> do. :) Right now I'm just trying to make sure we don't accidentally
> paint ourselves into a corner with a stable ABI.
>   

The stable ABI here is just the support baseline, not a freeze.  We know 
for certain that changes are needed for smp, paravirt drivers, new 
hardware virtualization extensions, and new archs.  And of course it 
only holds for x86; other archs will stabilize when they are ready.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV