Re: [Qemu-devel] [PATCH v2 0/2] monitor+disas: Remove uses of ENV_GET_CPU
Peter Crosthwaite crosthwaitepe...@gmail.com writes: Neither the monitor or disassembly core has a good reason to navigate from an env pointer to a cpu pointer. Disas should not need env awarness at all, that is removed in P2. The monitor is trickier, the env is still needed by some #ifdef switched target specific code but all common code only needs to trade in CPU pointers. As the monitor always has access to a CPU pointer naturally, remove ENV_GET_CPU usages (P1). This is related to my multi-arch work, where the goal is to minimise use of architecture defined global definitions, ENV_GET_CPU being a major headache in that whole effort. The longer term goal is to limit ENV_GET_CPU use to genuinely architecture specific code. But I think these two patches stand in their own right, so sending ahead of the motherload series. This brings both modules closer to common-oby-y'ification. First RFC for multi arch is avaiable here: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg01771.html The two patches are done together to avoid a conflict with monitor_disas which is touched by both patches. If one patch gets acked, the other nacked then either can be merged independently with trivial edits. Applied to my (badly named) qapi-next branch, thanks!
Re: [Qemu-devel] [PATCH v2 0/2] monitor+disas: Remove uses of ENV_GET_CPU
On Sun, 24 May 2015 14:20:39 -0700 Peter Crosthwaite crosthwaitepe...@gmail.com wrote: Neither the monitor or disassembly core has a good reason to navigate from an env pointer to a cpu pointer. Disas should not need env awarness at all, that is removed in P2. The monitor is trickier, the env is still needed by some #ifdef switched target specific code but all common code only needs to trade in CPU pointers. As the monitor always has access to a CPU pointer naturally, remove ENV_GET_CPU usages (P1). This is related to my multi-arch work, where the goal is to minimise use of architecture defined global definitions, ENV_GET_CPU being a major headache in that whole effort. The longer term goal is to limit ENV_GET_CPU use to genuinely architecture specific code. But I think these two patches stand in their own right, so sending ahead of the motherload series. This brings both modules closer to common-oby-y'ification. First RFC for multi arch is avaiable here: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg01771.html The two patches are done together to avoid a conflict with monitor_disas which is touched by both patches. If one patch gets acked, the other nacked then either can be merged independently with trivial edits. Unfortunately, I'm quite busy and won't have time to push this through my tree. Markus is going to pick up this series soon. Acked-by: Luiz Capitulino lcapitul...@redhat.com Changed since v1: Addressed RH and Andreas comments on P1. Peter Crosthwaite (2): monitor: Split mon_get_cpu fn to remove ENV_GET_CPU disas: Remove uses of CPU env disas.c | 14 +- include/disas/disas.h | 4 +-- include/qemu/log.h| 4 +-- monitor.c | 65 +++ target-alpha/translate.c | 2 +- target-arm/translate-a64.c| 2 +- target-arm/translate.c| 2 +- target-cris/translate.c | 2 +- target-i386/translate.c | 2 +- target-lm32/translate.c | 2 +- target-m68k/translate.c | 2 +- target-microblaze/translate.c | 2 +- target-mips/translate.c | 2 +- target-openrisc/translate.c | 2 +- target-ppc/translate.c| 2 +- target-s390x/translate.c | 2 +- target-sh4/translate.c| 2 +- target-sparc/translate.c | 2 +- target-tricore/translate.c| 2 +- target-unicore32/translate.c | 2 +- target-xtensa/translate.c | 2 +- 21 files changed, 57 insertions(+), 64 deletions(-)
Re: [Qemu-devel] [PATCH v2 0/2] monitor+disas: Remove uses of ENV_GET_CPU
Ping! So there was some uncertainty around maintainerships earlier (on some follow up work to this one) and I wonder what the target queue is for this stuff. Can the monitor people perhaps ack/nack P1? Regards, Peter On Sun, May 24, 2015 at 2:20 PM, Peter Crosthwaite crosthwaitepe...@gmail.com wrote: Neither the monitor or disassembly core has a good reason to navigate from an env pointer to a cpu pointer. Disas should not need env awarness at all, that is removed in P2. The monitor is trickier, the env is still needed by some #ifdef switched target specific code but all common code only needs to trade in CPU pointers. As the monitor always has access to a CPU pointer naturally, remove ENV_GET_CPU usages (P1). This is related to my multi-arch work, where the goal is to minimise use of architecture defined global definitions, ENV_GET_CPU being a major headache in that whole effort. The longer term goal is to limit ENV_GET_CPU use to genuinely architecture specific code. But I think these two patches stand in their own right, so sending ahead of the motherload series. This brings both modules closer to common-oby-y'ification. First RFC for multi arch is avaiable here: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg01771.html The two patches are done together to avoid a conflict with monitor_disas which is touched by both patches. If one patch gets acked, the other nacked then either can be merged independently with trivial edits. Changed since v1: Addressed RH and Andreas comments on P1. Peter Crosthwaite (2): monitor: Split mon_get_cpu fn to remove ENV_GET_CPU disas: Remove uses of CPU env disas.c | 14 +- include/disas/disas.h | 4 +-- include/qemu/log.h| 4 +-- monitor.c | 65 +++ target-alpha/translate.c | 2 +- target-arm/translate-a64.c| 2 +- target-arm/translate.c| 2 +- target-cris/translate.c | 2 +- target-i386/translate.c | 2 +- target-lm32/translate.c | 2 +- target-m68k/translate.c | 2 +- target-microblaze/translate.c | 2 +- target-mips/translate.c | 2 +- target-openrisc/translate.c | 2 +- target-ppc/translate.c| 2 +- target-s390x/translate.c | 2 +- target-sh4/translate.c| 2 +- target-sparc/translate.c | 2 +- target-tricore/translate.c| 2 +- target-unicore32/translate.c | 2 +- target-xtensa/translate.c | 2 +- 21 files changed, 57 insertions(+), 64 deletions(-) -- 1.9.1
Re: [Qemu-devel] [PATCH v2 0/2] monitor+disas: Remove uses of ENV_GET_CPU
On Tue, 2 Jun 2015 01:06:11 -0700 Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Ping! So there was some uncertainty around maintainerships earlier (on some follow up work to this one) and I wonder what the target queue is for this stuff. It's the monitor queue, for which I'm the maintainer. But I won't have to go over patches this week. If Markus, or any other maintainer, wants to take this one and the other patches I have queued through their trees, that would be more than welcome.
