qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Remove unneeded function parameter from gen_pc_


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH] Remove unneeded function parameter from gen_pc_load
Date: Sun, 17 Apr 2011 23:07:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Iceowl/1.0b1 Icedove/3.0.11

Am 17.04.2011 20:27, schrieb Aurelien Jarno:
On Thu, Apr 14, 2011 at 08:50:00PM +0200, Stefan Weil wrote:
Am 13.04.2011 23:05, schrieb Peter Maydell:
On 13 April 2011 21:38, Stefan Weil <address@hidden> wrote:
gen_pc_load was introduced in commit
d2856f1ad4c259e5766847c49acbb4e390731bd4.
The only reason for parameter searched_pc was
a debug statement in target-i386/translate.c.

Remove searched_pc from the debug statement
and from the parameter list of gen_pc_load.

No issues with the meat of the patch, but if we're going to
change all the callers and implementations of this anyway,
is there any appetite for giving it a more appropriate name?
It doesn't generate any code, it affects more than just the
pc, and it doesn't do a load...

restore_state_to_opc() ? set_env_for_opc() ?

-- PMM


What about cpu_restore_pc()? That's not always the whole truth,
but it's always the main action done in function n.n. which currently
is called gen_pc_load.

Or cpu_restore_helper()? Helper is very generic - it always fits.

Aurelien, please feel free to choose a name which suits bests.
I don't mind if you simply patch my patch, create a new one
or tell me which name should go into a new version of the patch
so I can send it.


As Peter said, the function is doing more than simply restoring the
pc. I am fine with the name he proposed, I think restore_state_to_opc()
is a bit better.

Ok, so I'll send a new patch which also replaces gen_pc_load
by restore_state_to_op. The new function name is longer than
the old one, but it was possible to remove one more function
parameter, therefore line lengths don't increase.

avoid over



reply via email to

[Prev in Thread] Current Thread [Next in Thread]