WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching

To: Chris Wright <chrisw@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 23 Mar 2006 09:25:28 +0000
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>
Delivery-date: Thu, 23 Mar 2006 09:26:44 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060323004006.GQ15997@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200603131802.k2DI2nv8005665@xxxxxxxxxxxxxxxxxxx> <200603222115.46926.ak@xxxxxxx> <20060322214025.GJ15997@xxxxxxxxxxxxxxxxxx> <4421EC44.7010500@xxxxxxxxxx> <20060323004006.GQ15997@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 23 Mar 2006, at 00:40, Chris Wright wrote:

Would you have less trouble if the "ROM" were actually more like a
module?  Specifically, if it had a proper elf header and symbol table,
used symbols as entry points, and was a GPL interface (so that ROM's had to be GPL)? Then it's just a kernel module that's hidden in the option
ROM space and has a C interface.

Yeah, point is the interface is normal C API, and has the similar free
form that normal kernel API's have.

i think this sounds very sane, and an OS-specific interface shim gets around problems such as finding CPU-specific state -- we can get at smp_processor_id() just the same as the rest of the kernel, for example. We could extend the concept of the interface shim we already have -- a set of OS-specific high performance shims, plus a fallback OS-agnostic shim.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>