[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0703091022490.10832@woody.linux-foundation.org>
Date: Fri, 9 Mar 2007 10:30:01 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
cc: Jeremy Fitzhardinge <jeremy@...p.org>,
Zachary Amsden <zach@...are.com>,
Thomas Gleixner <tglx@...utronix.de>,
john stultz <johnstul@...ibm.com>, akpm@...ux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
Chris Wright <chrisw@...s-sol.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: ABI coupling to hypervisors via CONFIG_PARAVIRT
On Fri, 9 Mar 2007, Ingo Molnar wrote:
>
> yes - but we already support the raw hardware ABI, in the native kernel.
Why do you continue to call paravirt an ABI?
We got over that. It's not. It's an API.
VMI is an ABI.
As long as you try to confuse the two, there's no point to the discussion.
Yeah, paravirt is ugly. Yeah, the calls should be moved higher in the
stack. But you don't help by confusing the issue by mixing the different
parts up and calling something an ABI that simply *isn't*.
Paravirt already acts on a higher level than the ioapic. It does do the
"irq_disable()" kind of "highlevel" callbacks. Yeah, the "apic_write()"
ones should go away, and they're just hacky, but there's nothing there
that is an ABI.
So just *fix* it or tell others to fix it, instead of just confusing the
issue.
And trust me, if "apic_write" causes bugs because it interacts with real
APIC usage, we don't care ONE WHIT. That paravirt_ops entry goes out the
window so fast you can't say "Whaa?!??".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists