From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yg8OX-0007PP-8g for qemu-devel@nongnu.org; Thu, 09 Apr 2015 05:05:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yg8OS-0008OQ-9P for qemu-devel@nongnu.org; Thu, 09 Apr 2015 05:05:05 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:35979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yg8OS-0008OK-5a for qemu-devel@nongnu.org; Thu, 09 Apr 2015 05:05:00 -0400 Received: by igblo3 with SMTP id lo3so61298325igb.1 for ; Thu, 09 Apr 2015 02:04:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150409085537.GA30629@toto> References: <1428437400-8474-1-git-send-email-peter.maydell@linaro.org> <1428437400-8474-2-git-send-email-peter.maydell@linaro.org> <20150409085537.GA30629@toto> From: Peter Maydell Date: Thu, 9 Apr 2015 10:04:39 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 01/14] memory: Define API for MemoryRegionOps to take attrs and return status List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: Peter Crosthwaite , Patch Tracking , QEMU Developers , Greg Bellows , Paolo Bonzini , =?UTF-8?B?QWxleCBCZW5uw6ll?= , Richard Henderson On 9 April 2015 at 09:55, Edgar E. Iglesias wrote: > Did you consider using a struct here? > e.g: > > typedef struct MemTxAttrs { > unsigned int secure : 1; > unsigned int master_id : 10; > unsigned int etc : 1; > } MemTxAttrs; > > I think you could still pass it by value and my understanding is > that the compiler will generate similar code. We discussed this last time round, I think. Whether structs get passed in registers depends on the host CPU ABI/calling convention. > I find it more readable, you ca go: > > attrs.secure = 1; > attrs.master_id = 0x77; > if (!attrs.secure) > > instead of: > > attrs |= MEMTXATTRS_SECURE > if (!(attrs & MEMTXATTRS_SECURE)) > > etc... > > Or do you see any disadvantages with this? I prefer the traditional integer-and-bitops approach, then you know what you're getting everywhere... -- PMM