From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50124 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OTcvg-0004ub-T3 for qemu-devel@nongnu.org; Tue, 29 Jun 2010 11:40:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OTcvf-0002Tg-9F for qemu-devel@nongnu.org; Tue, 29 Jun 2010 11:40:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17638) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OTcvf-0002TZ-0Q for qemu-devel@nongnu.org; Tue, 29 Jun 2010 11:40:55 -0400 Message-ID: <4C2A13FB.9080907@redhat.com> Date: Tue, 29 Jun 2010 17:40:43 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1277745445-30560-1-git-send-email-pbonzini@redhat.com> <4C29FA67.3070605@redhat.com> <4C2A021B.4010802@redhat.com> <201006291628.09556.paul@codesourcery.com> In-Reply-To: <201006291628.09556.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 4/4] require #define NEED_GLOBAL_ENV for files that need the global register variable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org On 06/29/2010 05:28 PM, Paul Brook wrote: >> 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? 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. In theory, a hypothetical KVM-only/no-TCG version of QEMU would not need to include neither exec-all.h nor target-*/exec.h. Paolo