From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [FW: FYI: The plan for Xen kernels in Fedora 9] Date: Tue, 11 Dec 2007 11:24:26 -0800 Message-ID: <475EE3EA.9000106@goop.org> References: <20071210152025.GF12703@redhat.com> <200712102138.50396.mark.williamson@cl.cam.ac.uk> <475DB415.70705@goop.org> <1197394361.8541.10.camel@sisko.scot.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1197394361.8541.10.camel@sisko.scot.redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Stephen C. Tweedie" Cc: "Daniel P. Berrange" , "xen-devel@lists.xensource.com" , Mark Williamson List-Id: xen-devel@lists.xenproject.org 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