From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzVPL-0008K5-3s for qemu-devel@nongnu.org; Mon, 01 Jun 2015 15:29:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzVPG-0002a7-52 for qemu-devel@nongnu.org; Mon, 01 Jun 2015 15:29:59 -0400 Received: from mail-qg0-x235.google.com ([2607:f8b0:400d:c04::235]:33665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzVPG-0002Zr-0n for qemu-devel@nongnu.org; Mon, 01 Jun 2015 15:29:54 -0400 Received: by qgfa63 with SMTP id a63so51346138qgf.0 for ; Mon, 01 Jun 2015 12:29:53 -0700 (PDT) Sender: Richard Henderson Message-ID: <556CB2AD.2070704@twiddle.net> Date: Mon, 01 Jun 2015 12:29:49 -0700 From: Richard Henderson MIME-Version: 1.0 References: <556C10F2.9080607@redhat.com> In-Reply-To: <556C10F2.9080607@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 14/34] cpu-defs: Allow multiple inclusions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Peter Crosthwaite , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, edgar.iglesias@gmail.com, afaerber@suse.de, Peter Crosthwaite On 06/01/2015 12:59 AM, Paolo Bonzini wrote: > > > On 31/05/2015 08:11, Peter Crosthwaite wrote: >> Allow subsequent inclusion of cpu-defs.h. This allows including >> multiple cpu.h's and each getting the right set of definitions for >> its env structure definition. All define symbols are undeffed and >> redeffed to the new values. >> >> CPUTLBEntry and CPUIOTLBEntry need to be renamed via #define by >> the caller to avoid namespace collisions. > > Please document these things (#undeffing of preprocessor symbols and > what needs to be renamed) in the header. > > Also the same is true for include/exec/target-long.h---where > additionally I am not sure about how you'd deal with a redefined > typedef. Some compilers flag it as an error even if the source type is > the same. Whee, I'm not alone in my curiosity. Of course, one way around this is to make target_[u]long be defines instead of typedefs. Whether that's a sufficient solution, I have no idea. That said, I think I'm also missing the point of multiple-inclusion. Perhaps it'll become clearer in a patch I haven't seen yet. r~