From: Chris Wright <chrisw@sous-sol.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
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 11:00:40 -0800 [thread overview]
Message-ID: <20070309190040.GQ10574@sequoia.sous-sol.org> (raw)
In-Reply-To: <20070309180230.GA17988@elte.hu>
* Ingo Molnar (mingo@elte.hu) wrote:
> i claim that when the 'API cut' is done at the right level then no more
> than say 100 hooks would be needed - with virtually zero kernel size
> increase. We've got all the right highlevel abstractions: genirq, gtod,
> clockevents. Whatever is missing at the moment from the framework (say
> smp_send_reschedule()) we can abstract away. The bonus? It would be
> almost directly applicable to other architectures as well. It would also
> work with /any/ hypervisor.
Oddly enough, that's really what we are trying to acheive. There is
definitely some tension between the VMI model which is modeled very
directly on hardware and something like the Xen model which prefers
higher level interfaces.
I don't really agree with your metrics w.r.t hooks. My point is you
take callsites == hooks to arrive at 1463 hook, but then above say 100
hooks is sufficient. But we have on the order of 100 hooks (I believe
it's ~75 in Linus' tree). Put it another way. Do you believe that
something like irq_{en,dis}able() is appropriate to hook (as that's >
1400 callsites already)?
> Firstly, i think this has been over-rushed. After years of being happy
> with forks of the Linux kernel, all the hypervisors woke up at once and
> want to have their stuff upstream /now/. This rush created a hodgepodge
> of APIs/ABIs that we now in the end promise to support /all/. (if we
> take CONFIG_VMI i can see little ethical reason to not take Xen's
> paravirt_ops, lguest's paravirt_ops, KVM's paravirt_ops and i'm sure
> Microsoft/Novell will have something nice and different for us too.)
It would be imminently helpful if you helped with some specific ideas
on where the paravirt_ops interface needs to be adjusted.
> Secondly, i'd like to see a paravirt approach that has /implicit/
> safeguards against the following type of crap:
How would you propose doing that? Typically that's done with code
review and patches.
thanks,
-chris
prev parent reply other threads:[~2007-03-09 19:02 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-09 18:02 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
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 [this message]
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=20070309190040.GQ10574@sequoia.sous-sol.org \
--to=chrisw@sous-sol.org \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jeremy@goop.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=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
all inboxes | Powered by JetHome®