From: Scott Wood <scottwood@freescale.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Alexander Graf <agraf@suse.de>,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH 1/3] PPC: Clean up misuse of qdev_init() in kvm-openpic creation
Date: Tue, 24 Feb 2015 18:04:26 -0600 [thread overview]
Message-ID: <1424822666.4698.37.camel@freescale.com> (raw)
In-Reply-To: <87egpnz3eq.fsf@blackfin.pond.sub.org>
On Wed, 2015-02-18 at 15:43 +0100, Markus Armbruster wrote:
> Scott, can you review?
>
> Markus Armbruster <armbru@redhat.com> writes:
>
> > We call ppce500_init_mpic_kvm() to create a "kvm-openpic". If it
> > fails, we call ppce500_init_mpic_qemu() to fall back to plain
> > "openpic".
> >
> > ppce500_init_mpic_kvm() uses qdev_init(). qdev_init()'s error
> > handling has an unwanted side effect: it calls qerror_report_err(),
> > which prints to stderr. Looks like an error, but isn't.
> >
> > In QMP context, it would stash the error in the monitor instead,
> > making the QMP command fail. Fortunately, it's only called from board
> > initialization, never in QMP context.
> >
> > Clean up by cutting out the qdev_init() middle-man: set property
> > "realized" directly.
> >
> > While there, improve the error message when we can't satisfy an
> > explicit user request for "kvm-openpic", and exit(1) instead of
> > abort().
I'm OK with this if setting the realized property directly is considered
good practice, but if we're not supposed to call qdev_init() in cases
where it could legitimately fail, why is it distinct from
qdev_init_nofail()?
-Scott
next prev parent reply other threads:[~2015-02-25 2:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 9:34 [Qemu-devel] [PATCH 0/3] Clean up misuse of qdev_init() in interrupt controller creation Markus Armbruster
2015-02-05 9:34 ` [Qemu-devel] [PATCH 1/3] PPC: Clean up misuse of qdev_init() in kvm-openpic creation Markus Armbruster
2015-02-18 14:43 ` Markus Armbruster
2015-02-25 0:04 ` Scott Wood [this message]
2015-02-25 9:32 ` Markus Armbruster
2015-02-05 9:34 ` [Qemu-devel] [PATCH 2/3] spapr: Clean up misuse of qdev_init() in xics-kvm creation Markus Armbruster
2015-02-18 14:42 ` Markus Armbruster
2015-02-23 0:31 ` David Gibson
2015-02-20 13:16 ` Alexander Graf
2015-02-05 9:34 ` [Qemu-devel] [PATCH 3/3] s390x: Replace unchecked qdev_init() by qdev_init_nofail() Markus Armbruster
2015-02-18 14:45 ` Markus Armbruster
2015-02-18 15:31 ` Cornelia Huck
2015-03-10 11:56 ` Cornelia Huck
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=1424822666.4698.37.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.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 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.