qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 4/4] require #define NEED_GLOBAL_ENV for files t


From: Paul Brook
Subject: [Qemu-devel] Re: [PATCH 4/4] require #define NEED_GLOBAL_ENV for files that need the global register variable
Date: Tue, 29 Jun 2010 16:28:09 +0100
User-agent: KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.4; x86_64; ; )

> On 06/29/2010 03:51 PM, Paolo Bonzini wrote:
> > On 06/29/2010 01:30 PM, Paul Brook wrote:
> >> I don't understand what this is supposed to achieve. The inclusion
> >> of exec.h is what defines whether this global variable is
> >> available. Just as importantly, it also prevents code clobbering
> >> this value. Having one without the other makes no sense.
> >> 
> >> Making "env" available without including exec.h would be a
> >> different problem, but we never do that and would probably indicate
> >> we're doing something else wrong.
> > 
> > Paul, I agree but I was told to do something different.
> 
> 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?

Paul



reply via email to

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