All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.