> >> BTW, this may be useful for one thing: being able to include exec.h > >> without bringing in the global variable. > > > > I'd argue that's not a desirable feature. I'd much rather have exec.h be > > the controlling factor than have all files include the same set of > > headers and have semantics determined by some combination of > > preprocessor macros. > > > > I realise we already have this with NEED_CPU_H, however I don't think > > that's a precedent we want to encourage. > > > >> I didn't really see a use right now for that, but cpu_get_tb_cpu_state > >> could be something that may belong in target-*/exec.h more than in > >> target-*/cpu.h (no, I'm not going to move it); yet it cannot be moved > >> right now because it is called in exec.c. > > > > How is putting it in exec.h better? > > I see cpu.h as holding things related to the CPU as a hardware device, > and exec.h as holding things related to emulation of the CPU.
If you really want NEED_GLOBAL_ENV then your implementation is nowhere near sufficient. One of the main reasons we have exec.h is that you may not call GLOBAL_ENV code from regular code[1]. Doing so will result in qemu crashing. The current system is simple to understand and audit: All prototypes for code that includes exec.h must go in exec.h. Once you introduce NEED_GLOBAL_ENV you have both safe and unsafe code in exec.h. All unsafe code should be protected by proper #idefs. I have low confidence in being able to get this right. If you want to split out the TCG specific bits of cpu.h (including things like cpu_halted which are currently in exec.h but don't use global env) then I suggest creating a new header file for this. Paul [1] cpu_exec() is a special case, and jumps though hoops to make this work.
