All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.