From: Rusty Russell <rusty@rustcorp.com.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@suse.de>, Zachary Amsden <zach@vmware.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Avi Kivity <avi@qumranet.com>,
Glauber de Oliveira Costa <glommer@gmail.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: [PATCH RFC REPOST 1/2] paravirt: refactor struct paravirt_ops into smaller pv_*_ops
Date: Fri, 12 Oct 2007 00:01:51 +1000 [thread overview]
Message-ID: <200710120001.52456.rusty@rustcorp.com.au> (raw)
In-Reply-To: <470D13CA.3000202@goop.org>
On Thursday 11 October 2007 04:02:50 Jeremy Fitzhardinge wrote:
> >> struct paravirt_ops paravirt_ops = {
> >
> > ...
> >
> >> + .pv_info = {
> >> + .name = "bare hardware",
> >> + .paravirt_enabled = 0,
> >> + .kernel_rpl = 0,
> >> + .shared_kernel_pmd = 1, /* Only used when CONFIG_X86_PAE is set */
> >> + },
> >
> > This is the bit I don't get. Why not just declare struct pv_info pvinfo,
> > etc, and use the declaration of struct paravirt_ops to get your unique
> > offset-based identifiers for patching?
>
> Given an op id number in .parainstructions, the patching code needs to
> be able to index into something to get the corresponding function
> pointer. If each pv_* structure is its own little unrelated structure,
> then the id has to be a <structure, id> tuple, which just complicates
> things. If I pack them all into a single structure then it becomes a
> simple offset calculation.
Sure, but this can actually be a temporary thing inside the patch code (or at
least static to that file if it's too big for the stack).
struct paravirt_ops patch_template = { .pv_info = pv_info, .pv_cpu_ops =
pv_cpu_ops, ... };
Then you can even rename struct paravirt_ops to "struct patch_template" and
we're well on the way to making this a generic function-call patching
mechanism, rather than something paravirt-specific.
Hope that clarifies my thinking...
Rusty.
next prev parent reply other threads:[~2007-10-11 14:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-09 18:24 [PATCH RFC REPOST 1/2] paravirt: refactor struct paravirt_ops into smaller pv_*_ops Jeremy Fitzhardinge
2007-10-10 6:35 ` Rusty Russell
2007-10-10 17:48 ` Jeremy Fitzhardinge
2007-10-10 18:02 ` Jeremy Fitzhardinge
2007-10-11 14:01 ` Rusty Russell [this message]
2007-10-12 19:16 ` Jeremy Fitzhardinge
2007-10-12 19:16 ` Jeremy Fitzhardinge
2007-10-15 8:16 ` Rusty Russell
2007-10-15 19:23 ` Jeremy Fitzhardinge
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=200710120001.52456.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ak@suse.de \
--cc=anthony@codemonkey.ws \
--cc=avi@qumranet.com \
--cc=glommer@gmail.com \
--cc=jeremy@goop.org \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.osdl.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 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.