public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Chris Wright <chrisw@sous-sol.org>
Cc: Andi Kleen <ak@suse.de>,
	virtualization@lists.osdl.org, Linus Torvalds <torvalds@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Xen-devel <xen-devel@lists.xensource.com>,
	Andrew Morton <akpm@osdl.org>, Dan Hecht <dhecht@vmware.com>,
	Dan Arai <arai@vmware.com>, Anne Holler <anne@vmware.com>,
	Pratap Subrahmanyam <pratap@vmware.com>,
	Christopher Li <chrisl@vmware.com>,
	Joshua LeVasseur <jtl@ira.uka.de>, Rik Van Riel <riel@redhat.com>,
	Jyothy Reddy <jreddy@vmware.com>, Jack Lo <jlo@vmware.com>,
	Kip Macy <kmacy@fsmware.com>, Jan Beulich <jbeulich@novell.com>,
	Ky Srinivasan <ksrinivasan@novell.com>,
	Wim Coekaerts <wim.coekaerts@oracle.com>,
	Leendert van Doorn <leendert@watson.ibm.com>
Subject: Re: [RFC, PATCH 5/24] i386 Vmi code patching
Date: Wed, 22 Mar 2006 20:04:38 -0800	[thread overview]
Message-ID: <44221E56.7030006@vmware.com> (raw)
In-Reply-To: <20060323010627.GS15997@sorel.sous-sol.org>

Chris Wright wrote:
> * Zachary Amsden (zach@vmware.com) 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

  reply	other threads:[~2006-03-23  4:04 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-13 18:02 [RFC, PATCH 5/24] i386 Vmi code patching Zachary Amsden
2006-03-15 10:02 ` Chris Wright
2006-03-15 16:01   ` Zachary Amsden
2006-03-15 22:05 ` Anthony Liguori
2006-03-15 23:00 ` Pavel Machek
2006-03-17  0:51   ` Zachary Amsden
2006-03-17 10:08   ` Joshua LeVasseur
2006-03-17 21:11     ` Chris Wright
2006-03-18  0:49       ` Joshua LeVasseur
2006-03-16 19:10 ` Jan Engelhardt
2006-03-16 19:45   ` Rik van Riel
2006-03-16 21:54     ` Zachary Amsden
2006-03-22 20:15 ` Andi Kleen
2006-03-22 21:40   ` Chris Wright
2006-03-22 22:16     ` Zachary Amsden
2006-03-22 22:33       ` Daniel Arai
2006-03-22 23:02         ` Chris Wright
2006-03-22 22:51       ` Chris Wright
2006-03-22 23:36         ` Zachary Amsden
2006-03-23  0:41           ` Chris Wright
2006-03-23  0:54             ` Zachary Amsden
2006-03-23  1:06               ` Chris Wright
2006-03-23  4:04                 ` Zachary Amsden [this message]
2006-03-23 11:42                 ` Joshua LeVasseur
2006-03-23  0:31     ` Anthony Liguori
2006-03-23  0:40       ` Chris Wright
2006-03-23  9:25         ` Keir Fraser
2006-03-23 18:50           ` [Xen-devel] " Zachary Amsden
2006-03-23 23:45           ` Eli Collins
2006-03-23  0:46       ` Zachary Amsden
2006-03-23  0:53         ` Anthony Liguori
2006-03-23  1:01           ` Zachary Amsden
  -- strict thread matches above, loose matches on Subject: below --
2006-03-22 23:41 Volkmar Uhlig
2006-03-28  0:52 Chuck Ebbert
2006-03-28  1:48 ` Zachary Amsden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44221E56.7030006@vmware.com \
    --to=zach@vmware.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=anne@vmware.com \
    --cc=arai@vmware.com \
    --cc=chrisl@vmware.com \
    --cc=chrisw@sous-sol.org \
    --cc=dhecht@vmware.com \
    --cc=jbeulich@novell.com \
    --cc=jlo@vmware.com \
    --cc=jreddy@vmware.com \
    --cc=jtl@ira.uka.de \
    --cc=kmacy@fsmware.com \
    --cc=ksrinivasan@novell.com \
    --cc=leendert@watson.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pratap@vmware.com \
    --cc=riel@redhat.com \
    --cc=torvalds@osdl.org \
    --cc=virtualization@lists.osdl.org \
    --cc=wim.coekaerts@oracle.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox