From: Laszlo Ersek <lersek@redhat.com>
To: armbru@redhat.com
Cc: aliguori@us.ibm.com, mjt@tls.msk.ru, qemu-devel@nongnu.org,
agraf@suse.de, blauwirbel@gmail.com, qemu-ppc@nongnu.org,
aviksil@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v4 3/6] sun4: Don't prematurely explode QEMUMachineInitArgs
Date: Sat, 17 Aug 2013 12:29:54 +0200 [thread overview]
Message-ID: <520F50A2.7090108@redhat.com> (raw)
In-Reply-To: <1376651630-9151-4-git-send-email-armbru@redhat.com>
comments below
On 08/16/13 13:13, armbru@redhat.com wrote:
> From: Markus Armbruster <armbru@redhat.com>
>
> Don't explode QEMUMachineInitArgs before passing it to
> sun4m_hw_init(), sun4uv_init().
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
> hw/sparc/sun4m.c | 113 ++++++++++++-----------------------------------------
> hw/sparc64/sun4u.c | 52 +++++++-----------------
> 2 files changed, 40 insertions(+), 125 deletions(-)
>
> diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
> index 942ca37..36ef36f 100644
> --- a/hw/sparc/sun4m.c
> +++ b/hw/sparc/sun4m.c
> @@ -836,12 +836,10 @@ static void dummy_fdc_tc(void *opaque, int irq, int level)
> {
> }
>
> -static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, ram_addr_t RAM_size,
> - const char *boot_device,
> - const char *kernel_filename,
> - const char *kernel_cmdline,
> - const char *initrd_filename, const char *cpu_model)
> +static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
> + QEMUMachineInitArgs *args)
> {
> + const char *cpu_model = args->cpu_model;
This may not be strictly necessary; in the first patch you modify
args->cpu_model too.
In any case the above is not wrong.
> @@ -878,13 +875,15 @@ static void sun4uv_init(MemoryRegion *address_space_mem,
>
> initrd_size = 0;
> initrd_addr = 0;
> - kernel_size = sun4u_load_kernel(kernel_filename, initrd_filename,
> + kernel_size = sun4u_load_kernel(args->kernel_filename,
> + args->initrd_filename,
> ram_size, &initrd_size, &initrd_addr,
> &kernel_addr, &kernel_entry);
The patch is correct / faithful here, but I smell some fubar in the code
that the patch keeps intact.
"ram_size" is apparently the global variable from "vl.c". So this
function gets the RAM size twice, once via RAM_size / args->ram_size,
then via the "ram_size" global. (They should have identical values,
"args.ram_size" in main() is initialized with "ram_size" the global.)
The rest of the code below this hunk (in the full source file, not just
in the patch) alternates between RAM_size / args->ram_size and
"ram_size" quite schizophrenically too; see eg. FW_CFG_RAM_SIZE.
Anyway the patch only improves things.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
next prev parent reply other threads:[~2013-08-17 10:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 11:13 [Qemu-devel] [PATCH v4 0/6] Clean up bogus default boot order armbru
2013-08-16 11:13 ` [Qemu-devel] [PATCH v4 1/6] pc: Don't prematurely explode QEMUMachineInitArgs armbru
2013-08-17 10:07 ` Laszlo Ersek
2013-08-19 9:09 ` Markus Armbruster
2013-08-21 18:05 ` Eduardo Habkost
2013-08-16 11:13 ` [Qemu-devel] [PATCH v4 2/6] pc: Don't explode QEMUMachineInitArgs into local variables needlessly armbru
2013-08-17 10:12 ` Laszlo Ersek
2013-08-21 18:06 ` Eduardo Habkost
2013-08-16 11:13 ` [Qemu-devel] [PATCH v4 3/6] sun4: Don't prematurely explode QEMUMachineInitArgs armbru
2013-08-17 10:29 ` Laszlo Ersek [this message]
2013-08-19 9:15 ` Markus Armbruster
2013-08-16 11:13 ` [Qemu-devel] [PATCH v4 4/6] ppc: Don't explode QEMUMachineInitArgs into local variables needlessly armbru
2013-08-17 10:33 ` Laszlo Ersek
2013-08-16 11:13 ` [Qemu-devel] [PATCH v4 5/6] ppc: Don't duplicate QEMUMachineInitArgs in PPCE500Params armbru
2013-08-17 10:46 ` Laszlo Ersek
2013-08-19 9:24 ` Markus Armbruster
2013-08-19 9:36 ` Laszlo Ersek
2013-08-16 11:13 ` [Qemu-devel] [PATCH v4 6/6] hw: Clean up bogus default boot order armbru
2013-08-17 11:59 ` Laszlo Ersek
2013-08-21 20:28 ` [Qemu-devel] [PATCH v4 0/6] " Michael S. Tsirkin
2013-08-21 20:29 ` Michael S. Tsirkin
2013-08-23 12:31 ` Markus Armbruster
2013-08-25 11:10 ` Michael S. Tsirkin
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=520F50A2.7090108@redhat.com \
--to=lersek@redhat.com \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=aviksil@linux.vnet.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=mjt@tls.msk.ru \
--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 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).