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
next prev parent 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