From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55794 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OTlGG-0002Lu-Fi for qemu-devel@nongnu.org; Tue, 29 Jun 2010 20:34:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OTlGF-0001K6-Gi for qemu-devel@nongnu.org; Tue, 29 Jun 2010 20:34:44 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:43971) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OTlGF-0001Jo-7k for qemu-devel@nongnu.org; Tue, 29 Jun 2010 20:34:43 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 4/4] require #define NEED_GLOBAL_ENV for files that need the global register variable Date: Wed, 30 Jun 2010 01:34:38 +0100 References: <1277745445-30560-1-git-send-email-pbonzini@redhat.com> <201006291628.09556.paul@codesourcery.com> <4C2A13FB.9080907@redhat.com> In-Reply-To: <4C2A13FB.9080907@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201006300134.38531.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: blauwirbel@gmail.com, Paolo Bonzini > >> 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.