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: [patch 10/21] Xen-paravirt: Name: dont export paravirt_o

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Tue, 13 Feb 2007 17:18:21 -0800
Cc: Andrew Morton <akpm@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, Andi Kleen <ak@xxxxxx>
Delivery-date: Tue, 13 Feb 2007 17:17:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45D262DC.2020008@xxxxxxxx>
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: <20070213221729.772002682@xxxxxxxx> <20070213221830.238235953@xxxxxxxx> <45D260A2.4010200@xxxxxxxxxx> <45D262DC.2020008@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.9 (X11/20061206)
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
This turned out really hideous looking to me.  Can't we split the
struct into GPL'd and non-GPL'd functions instead?  We still have the
same granularity, and none of this function call to an indirect
function call nonsense.

It's not pretty, but I think having paravirt_ops and paravirt_ops_gpl
would be worse.  I'd be sympathetic to the idea of splitting
paravirt_ops up by function groupings, but splitting it by license seems
like a maintenance headache with no real upside.  Besides, patching will
solve everything (tm).

Ok. As long as we plan on patching CR2 and CR0 / clts accessors for FPU save during context switch and page fault paths in the future.

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

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