public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Liu Yu-B13201 <B13201@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	"agraf@suse.de" <agraf@suse.de>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH v5 1/4] KVM: PPC: epapr: Factor out the epapr init
Date: Wed, 22 Feb 2012 12:28:43 -0600	[thread overview]
Message-ID: <4F4533DB.7000505@freescale.com> (raw)
In-Reply-To: <4CA99838F21AB847ACC344051E23170905749AD7@039-SN2MPN1-022.039d.mgd.msft.net>

On 02/21/2012 08:33 PM, Liu Yu-B13201 wrote:
>>> +bool epapr_para_enabled = false;
>>
>> No need to explicitly initialize to false.
> 
> Why not make code more readable?

It's common kernel style to not explicitly initialize global data to
zero or equivalent.  Historically this was due to toolchain issues that
are no longer relevant, but people still seem to prefer it that way.
It's subjective whether readability is enhanced by being explicit or by
being concise.

>> Do not warn just because there's no hypervisor or hcall-instructions.
>> There's nothing wrong with that.  Only warn if they are present but wrong.
>>
> 
> I see that it's not proper to warn in host.
> But if user forget to add hypervisor node or inst, how can he know something is wrong?

Print a message when paravirt is enabled (I think KVM already does
this).  This is no different than a user forgetting to add a certain
device to the device tree -- you'll silently just not get that device.

Ideally the hypervisor would take care of adding this stuff to the
device tree anyway, no user action required.

-Scott


      reply	other threads:[~2012-02-22 18:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-21  4:46 [PATCH v5 1/4] KVM: PPC: epapr: Factor out the epapr init Liu Yu
2012-02-21  4:46 ` [PATCH v5 2/4] KVM: PPC: epapr: Add idle hcall support for host Liu Yu
2012-02-21  4:46   ` [PATCH v5 3/4] KVM: PPC: epapr: install ev_idle hcall for e500 guest Liu Yu
2012-02-21  4:46     ` [PATCH v5 4/4] KVM: PPC: epapr: Update other hypercall invoking Liu Yu
2012-02-21 21:57       ` Scott Wood
2012-02-22  2:34         ` Liu Yu-B13201
2012-02-21 10:53     ` [PATCH v5 3/4] KVM: PPC: epapr: install ev_idle hcall for e500 guest tiejun.chen
2012-02-22  2:29       ` Liu Yu-B13201
2012-02-22  2:51         ` tiejun.chen
2012-02-22  2:59           ` Liu Yu-B13201
2012-02-21 21:56 ` [PATCH v5 1/4] KVM: PPC: epapr: Factor out the epapr init Scott Wood
2012-02-22  2:33   ` Liu Yu-B13201
2012-02-22 18:28     ` Scott Wood [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=4F4533DB.7000505@freescale.com \
    --to=scottwood@freescale.com \
    --cc=B07421@freescale.com \
    --cc=B13201@freescale.com \
    --cc=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.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