From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z05U7-0000i5-Cv for qemu-devel@nongnu.org; Wed, 03 Jun 2015 06:01:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z05U1-0006h4-Nh for qemu-devel@nongnu.org; Wed, 03 Jun 2015 06:01:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z05U1-0006gy-ID for qemu-devel@nongnu.org; Wed, 03 Jun 2015 06:01:13 -0400 Message-ID: <556ED063.7070001@redhat.com> Date: Wed, 03 Jun 2015 12:01:07 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <74cc0d2f8d1d9d52638a1b3633e1a861b51907f4.1433052532.git.crosthwaite.peter@gmail.com> <556CB18A.6070305@twiddle.net> <556CB7DE.1080006@redhat.com> <556CC179.3020400@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 10/34] include/exec: Split target_long def to new header List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , Richard Henderson Cc: Peter Maydell , Peter Crosthwaite , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , "Edgar E. Iglesias" , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 02/06/2015 12:14, Peter Crosthwaite wrote: > The #define-always change does make for a cleaner end result but I > stayed away from it purely because I was thinking typedefs are better > for type-definitions. But if we are open to the change of the #define > based implementation I am all for it as the target-foo/cpu.h change > pattern in minimised. > > We still have a similar problems with cpu-defs.h/CPUTLBEntry though. I > have to think harder about how that can be done, but one solution is > to conditionally change the tlb_table defs in CPU_COMMON to be just a > dummy uint8_t[] in MULTI_ARCH case. This is ok, as the struct fields > are only accessible by arch-obj-y which will get the full-service > definition via non TARGET_MULTI_ARCH arch-obj-y compile. The work is > half done for us, as CPUTLBTable already has a uint8_t padding system > in place. I guess you would hardcode CPUTLBEntry to 32 bytes in this case. > CPUIOTLBEntry can be moved to another header as it has no arch specific deps. > > All in all, we can do this with 0 #define foo arm_foo in arch cpu.h's, > with these edits. That would be nice to see for v3. Paolo