From: "Andreas Färber" <afaerber@suse.de>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>,
Riku Voipio <riku.voipio@iki.fi>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/4] cpu: Make cpu_init() return QOM object
Date: Tue, 10 Mar 2015 18:02:11 +0100 [thread overview]
Message-ID: <54FF2393.5090009@suse.de> (raw)
In-Reply-To: <54F081E6.1050209@suse.de>
Am 27.02.2015 um 15:40 schrieb Andreas Färber:
> Hi Eduardo,
>
> Am 26.02.2015 um 21:37 schrieb Eduardo Habkost:
>> This series changes cpu_init() to return a CPU QOM object, and changes existing
>> arch-specific code to use the corresponding arch-specific function instead of
>> cpu_init().
>>
>> With this, the only remaining users of cpu_init() are linux-user and bsd-user.
>>
>> Eduardo Habkost (4):
>> target-unicore32: Make uc32_cpu_init() return UniCore32CPU
>> m68k: Use cpu_m68k_init()
>> unicore32: Use uc32_cpu_init()
>
> This part looks good to me. At the time, I propagated *CPU only for
> those machines that needed it for function calls or field accesses.
>
>> cpu: Make cpu_init() return QOM object
>
> As for this patch, the Coccinelle based approach looks cool! However I
> would like to give this a bit more thought as to whether 1) this causes
> churn with regards to the next steps I outlined, and 2) whether more
> simplifications can be done while at it. Could be done as follow-ups.
Not hearing any objection from machine maintainers, I've gone ahead and
applied the fourth patch as well:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu
One of the concerns I had was whether we might use cpu_generic_init() in
the macro directly, where applicable. But that seems to depend on
whether machines will continue to use FooCPU *cpu_foo_init(), which
depends on how we proceed with CPU (hot-plug) remodeling, etc.
Thanks,
Andreas
>
> Let's also keep in mind that target-tilegx patches are on the list.
>
> Regards,
> Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
prev parent reply other threads:[~2015-03-10 17:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 20:37 [Qemu-devel] [PATCH 0/4] cpu: Make cpu_init() return QOM object Eduardo Habkost
2015-02-26 20:37 ` [Qemu-devel] [PATCH 1/4] target-unicore32: Make uc32_cpu_init() return UniCore32CPU Eduardo Habkost
2015-02-26 20:37 ` [Qemu-devel] [PATCH 2/4] m68k: Use cpu_m68k_init() Eduardo Habkost
2015-02-26 20:37 ` [Qemu-devel] [PATCH 3/4] unicore32: Use uc32_cpu_init() Eduardo Habkost
2015-02-26 20:37 ` [Qemu-devel] [PATCH 4/4] cpu: Make cpu_init() return QOM object Eduardo Habkost
2015-03-10 16:16 ` Andreas Färber
2015-03-10 16:23 ` Andreas Färber
2015-03-10 16:35 ` Eduardo Habkost
2015-02-27 14:40 ` [Qemu-devel] [PATCH 0/4] " Andreas Färber
2015-03-10 17:02 ` Andreas Färber [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=54FF2393.5090009@suse.de \
--to=afaerber@suse.de \
--cc=blauwirbel@gmail.com \
--cc=ehabkost@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/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;
as well as URLs for NNTP newsgroup(s).