From: Rusty Russell <rusty@rustcorp.com.au>
To: "Glauber de Oliveira Costa" <glommer@gmail.com>
Cc: "Glauber de Oliveira Costa" <gcosta@redhat.com>,
lguest@ozlabs.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, rostedt@goodmis.org
Subject: Re: [PATCH 0/16] lguest: introduce vcpu structure
Date: Mon, 7 Jan 2008 11:53:57 +1100 [thread overview]
Message-ID: <200801071153.57710.rusty@rustcorp.com.au> (raw)
In-Reply-To: <5d6222a80801060933h7bc0d158h6e3b445c3db43291@mail.gmail.com>
On Monday 07 January 2008 04:33:53 Glauber de Oliveira Costa wrote:
> On Dec 25, 2007 9:54 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > My only question is whether we should go further and vpu-ify routines
> > like lgread and kill_guest, so that we can avoid more "lg" temporary
> > variables...
>
> Essentially, they don't need it, because they only touch
> globally-visible variables (visible to the guest).
> So it's more of an stylish thing. Using the vcpu in the signature can
> have only one harm:
> It needs the caller to also have a pointer to a vcpu, so we may end up
> using it everywhere, like a domino fall.
>
> Alternatively, in such functions that don't currently receive a vcpu
> (nor they need to), we can convention to always pass
> lg->vcpus[0] to lgread, kill_guest, etc. Which one do you prefer?
I'm happy with a domino effect. I don't want to see lg->vcpus[0] *anywhere*
though, because it's non-futureproof.
When I looked through these patches it seems to me that we should accept that
vcpu is now the basic guest unit, and lg exists to serve it. Otherwise I
think you can see the bones of the old UP code poking through, and that's
ugly.
Thanks!
Rusty.
prev parent reply other threads:[~2008-01-07 0:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-20 13:33 [PATCH 0/16] lguest: introduce vcpu structure Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 01/16] introduce vcpu struct Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 02/16] adapt lguest launcher to per-cpuness Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 03/16] initialize vcpu Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 04/16] per-cpu run guest Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 05/16] make write() operation smp aware Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 06/16] make hypercalls use the vcpu struct Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 07/16] per-vcpu lguest timers Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 08/16] per-vcpu interrupt processing Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 09/16] map_switcher_in_guest() per-vcpu Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 10/16] make emulate_insn receive a vcpu struct Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 11/16] make registers per-vcpu Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 12/16] replace lguest_arch with lguest_vcpu_arch Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 13/16] per-vcpu lguest task management Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 14/16] makes special fields be per-vcpu Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 15/16] make pending notifications per-vcpu Glauber de Oliveira Costa
2007-12-20 13:33 ` [PATCH 16/16] per-vcpu lguest pgdir management Glauber de Oliveira Costa
2007-12-25 23:47 ` [PATCH 13/16] per-vcpu lguest task management Rusty Russell
2007-12-25 23:47 ` [PATCH 09/16] map_switcher_in_guest() per-vcpu Rusty Russell
2007-12-25 23:40 ` [PATCH 05/16] make write() operation smp aware Rusty Russell
2007-12-25 23:38 ` [PATCH 04/16] per-cpu run guest Rusty Russell
2007-12-25 23:35 ` [PATCH 02/16] adapt lguest launcher to per-cpuness Rusty Russell
2007-12-26 14:24 ` Steven Rostedt
2007-12-27 0:08 ` Rusty Russell
2007-12-25 23:34 ` [PATCH 01/16] introduce vcpu struct Rusty Russell
2007-12-25 23:54 ` [PATCH 0/16] lguest: introduce vcpu structure Rusty Russell
2008-01-06 17:33 ` Glauber de Oliveira Costa
2008-01-07 0:53 ` Rusty Russell [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=200801071153.57710.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=gcosta@redhat.com \
--cc=glommer@gmail.com \
--cc=lguest@ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=virtualization@lists.linux-foundation.org \
/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