[RFC, PATCH 5/24] i386 Vmi code patching

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Chris Wright wrote:
> * Zachary Amsden (zach@xxxxxxxxxx) wrote:
>   
>> No, you don't need to dream up all the possible interface bits ahead of 
>> time.  With a la carte interfaces, you can take what you need now, and 
>> add features later.  You don't need an ABI for features.  You need it 
>> for compatibility.  You will need to update the hypervisor ABI.  And you 
>> can't force people to upgrade their kernels.
>>     
>
> How do you support an interface that's not already a part of the ABI
> w/out changing the kernel?
>   

You have to change the kernel for VMI interface upgrades - if you want 
to use the upgrades.  You don't need to change the kernel for hypervisor 
ABI changes, nor does upgrading the interface require a kernel change.  
Interface upgrades are pretty easy to compartmentalize - you add block 
device support, you add a block device driver.  Hypervisor ABI changes 
are not so easy, because of the data dependencies and potential for 
breaking compatibility.  The massive security hole scenario is a good 
example of why you would need to break compatibility, but any number of 
things might make you want to change the hypervisor ABI.

The point of the VMI is to isolate the kernel from those changes, 
allowing kernel development to proceed unhindered, and allowing 
hypervisor innovation to thrive simultaneously.

Zach

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux