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

[Jeremy Fitzhardinge <jeremy@goop.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