Am 28.10.2012 16:03, schrieb Blue Swirl: > In some cases it's pretty easy to avoid using global > cpu_single_env since a local version is available. > > Blue Swirl (5): > disas: avoid using cpu_single_env > kvm: avoid using cpu_single_env > target-unicore32: avoid using cpu_single_env > target-xtensa: avoid using cpu_single_env > target-i386: avoid using cpu_single_env
Each of these has been reviewed by at least a second pair of eyes now. I recently stumbled over cpu_single_env as an obstacle to actually using CPUState somewhere, so I'm happy about removing some occurrences. Have you considered using FooCPU arguments in target-specific code (e.g., last three) and decided against it? I checked that they build bisectably and still apply on top of my PULL; you being a committer, are you planning to apply these directly, or should I queue them for the next CPU pull and fix the messages myself? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
