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

Re: [Xen-devel] [FW: FYI: The plan for Xen kernels in Fedora 9]

To: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Subject: Re: [Xen-devel] [FW: FYI: The plan for Xen kernels in Fedora 9]
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 11 Dec 2007 11:24:26 -0800
Cc: "Daniel P. Berrange" <berrange@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Delivery-date: Tue, 11 Dec 2007 11:24:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1197394361.8541.10.camel@xxxxxxxxxxxxxxxxxxxxx>
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: <20071210152025.GF12703@xxxxxxxxxx> <200712102138.50396.mark.williamson@xxxxxxxxxxxx> <475DB415.70705@xxxxxxxx> <1197394361.8541.10.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (X11/20071115)
Stephen C. Tweedie wrote:
> But there are definitely places where the right upstream answer isn't
> obvious (eg, where mtrr meets pv_ops... both subsystems try to hide
> their internals behind an abstraction layer, so we need to break the
> abstractions somewhere to let pv_ops install an mtrr back-end.)  In such
> cases I'm having to make a decision quickly as to how things will go in
> just to get the tree progressing; but we'll have to go back and
> potentially rework a lot of that before it's actually upstreamable.
>   

Right.  pv_ops is all about adding interfaces where nothing suitable
existed before.  If there's an existing interface which is usable or
nearly usable, we've gone with that rather than extending pv_ops.  The
clocksource/clockevent interfaces are a good example of that.  If we can
hook into the mtrr machinery by registering a pseudo-cpu type, then that
would be neat.

Similarly, I'm hoping that the work on apic unification will give us an
interface we can hook the Xen apic machinery into without too much gross
hackery.

    J

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