public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Zachary Amsden <zach@vmware.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	john stultz <johnstul@us.ibm.com>,
	akpm@linux-foundation.org, LKML <linux-kernel@vger.kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>, Andi Kleen <ak@suse.de>,
	Chris Wright <chrisw@sous-sol.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: ABI coupling to hypervisors via CONFIG_PARAVIRT
Date: Fri, 9 Mar 2007 21:12:57 +0100	[thread overview]
Message-ID: <20070309201257.GA5761@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0703091137340.10832@woody.linux-foundation.org>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Similarly, maybe the VMI ABI doesn't allow for something that the 
> kernel wants to do efficiently. Big deal. What relevance does that 
> have to do with anything, except the fact that if true, the VMWare 
> people are screwed? It's *their* problem.

i wont hold you up for long, but i think this is the key difference, and 
if i understand your point correctly i think you are really wrong here.

This is 'enterprise Linux compatibility and ABI 101', really - i dare to 
bet blindly that you wont see anyone here from distros arguing against 
this simple point.

Once this thing is released upstream, it creates a new compatibility 
rule:

  _new kernel must not break on an older hypervisor_

due to a new paravirt_ops design. Ever. It's really that simple. (I 
think i never said this explicitly because this requirement of backwards 
compatibility was so obvious to me.)

And it doesnt matter whether we think that it was VMWare who messed up. 
Users/customers _will_ blame us: "v2.6.25 regresses, it wont run under 
ESX v1.12 anymore". Distro will yield and will undo whatever change 
breaks backwards compatibility with older hypervisors. (most likely it 
will be undone upstream already) Backwards compatibility acts as a very 
heavy barrier against certain types of paravirt_ops design changes.

Once v2.6.21 is released, and a bigger distro releases a kernel with 
CONFIG_PARAVIRT+CONFIG_VMI enabled: backwards compatibility in future 
versions becomes mainly /that/ distro's problem (and upstream's 
problem), _NOT_ WMware's problem.

That's why i mentioned CONFIG_COMPAT_VDSO as an example. One major 
distro (SuSE 9.0) came out with that particular glibc version that had a 
bug that depended on a particular and totally unintentional ABI detail 
in the vDSO. As a result we had to do several iterations of 
CONFIG_COMPAT_VDSO to keep backwards compatibility. And glibc is perhaps 
_the_ most kernel-friendly external software project in existence. 
Still, the ABI dependency was there, and we cannot break users who run 
old userspace. The same rule holds here: we cannot break users who run 
an old hypervisor.

	Ingo

  reply	other threads:[~2007-03-09 20:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-09 18:02 ABI coupling to hypervisors via CONFIG_PARAVIRT Ingo Molnar
2007-03-09 18:28 ` Andi Kleen
2007-03-09 18:30 ` Linus Torvalds
2007-03-09 19:24   ` Ingo Molnar
2007-03-09 19:51     ` Linus Torvalds
2007-03-09 20:12       ` Ingo Molnar [this message]
2007-03-09 21:05         ` Jeremy Fitzhardinge
2007-03-09 21:06         ` Linus Torvalds
2007-03-09 21:36           ` Ingo Molnar
2007-03-09 21:40             ` Jeremy Fitzhardinge
2007-03-09 22:27             ` Linus Torvalds
2007-03-09 22:50               ` Ingo Molnar
2007-03-09 23:07               ` Zachary Amsden
2007-03-09 23:10             ` Ingo Molnar
2007-03-09 23:38               ` Zachary Amsden
2007-03-09 21:04       ` Ingo Molnar
2007-03-09 21:27         ` Chris Wright
2007-03-09 21:47           ` Ingo Molnar
2007-03-09 21:59             ` Jeremy Fitzhardinge
2007-03-09 22:12               ` Ingo Molnar
2007-03-09 22:30                 ` Jeremy Fitzhardinge
2007-03-09 22:10             ` Chris Wright
2007-03-09 22:24               ` Ingo Molnar
2007-03-09 22:36                 ` Jeremy Fitzhardinge
2007-03-09 23:38                   ` Ingo Molnar
2007-03-09 22:46                 ` Chris Wright
2007-03-09 23:02                   ` Ingo Molnar
2007-03-09 23:13                 ` Rik van Riel
2007-03-09 20:50     ` Jan Engelhardt
2007-03-09 22:50       ` Lee Revell
2007-03-14  8:41         ` alsa was " Pavel Machek
2007-03-14 15:59           ` Jaroslav Kysela
2007-03-15  9:03             ` Pavel Machek
2007-03-15  9:10               ` Pavel Machek
2007-03-15  9:23                 ` Zachary Amsden
2007-03-15  9:32                   ` Pavel Machek
2007-03-09 19:00 ` Chris Wright

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070309201257.GA5761@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=chrisw@sous-sol.org \
    --cc=jeremy@goop.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=zach@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox