public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Chris Wright <chrisw@sous-sol.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>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: ABI coupling to hypervisors via CONFIG_PARAVIRT
Date: Fri, 09 Mar 2007 14:30:32 -0800	[thread overview]
Message-ID: <45F1E008.5000000@goop.org> (raw)
In-Reply-To: <20070309221233.GA24341@elte.hu>

Ingo Molnar wrote:
> yep. That's precisely my worry. And it doesnt have to be a 'great' thing 
> - just any random small change in the kernel that makes sense: what is 
> the likelyhood that it cannot be implemented, no matter what amount of 
> insight, paravirt_ops + hyper-ABI emulation hackery, for FoobieVisor, 
> because FoobieVisor messed up its ABI.
>
> that likelyhood is a pure function of how FoobieVisor's hypercall ABI is 
> shaped. Wow! So can you guess where my fixation about not having too 
> many ABIs could possibly originate from? ;-)
>   

OK, so its a problem that's happened before.  "It's a great idea, it's
so nice, but it breaks X."  Your options are:

   1. Well, nobody is really using X.  We can stop supporting it.
   2. X makes up 50% of the users, we'll just have to do without your
      great idea.
   3. Maybe we can get X updated so this idea works.

If X is a piece of hardware, then you're probably stuck with options 1
and 2.  If its something like firmware or a hypervisor, you might have a
chance with option 3.

The hypervisor interface is not at all special in this regard; you may
as well be arguing "We can't allow a port of Linux to the FoobieTron2000
CPU, because it might constrain some future development"; that's true,
it might.  But I don't think I've ever seen anyone make that argument
for not accepting a new architecture port.

I don't really understand what your overall argument is though.  Sure, I
guess its that if there's one ABI for all hypervisors, then you've only
got one hypervisor-related constraint to consider when evaluating a new
kernel change.  But that ABI is going to be as constraining as the its
most constraining hypervisor, so you're not really in a better position
than if you have N hypervisor ABIs.  In fact you're worse off, because
you have no flexibility to drop/adapt/whatever the real blocker.

> _Now_ at least i've got this minimal 
> admission that FoobieVisor _might_ break. Quite a breakthrough =B-)

If you went to all that typing to get that much of a concession, then
you have way too much time ;)

    J


  reply	other threads:[~2007-03-09 22:30 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
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 [this message]
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=45F1E008.5000000@goop.org \
    --to=jeremy@goop.org \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=chrisw@sous-sol.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --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