Re: [Qemu-devel] Re: [PATCH 4/4] require #define NEED_GLOBAL_ENV for files that need the global register variable

[Paul Brook]

> >> 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.