Re: [Qemu-devel] [PATCH 01/14] memory: Define API for MemoryRegionOps to take attrs and return status

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Fri, Apr 10, 2015 at 03:51:07PM +0100, Peter Maydell wrote:
> On 10 April 2015 at 03:07, Edgar E. Iglesias <edgar.iglesias@gmail.com> wrote:
> > On Thu, Apr 09, 2015 at 11:21:26AM +0200, Paolo Bonzini wrote:
> >> On 09/04/2015 11:04, Peter Maydell wrote:
> >> > We discussed this last time round, I think. Whether structs get
> >> > passed in registers depends on the host CPU ABI/calling convention.
> >>
> >> Because of C++, structs up to pointer size are in practice always passed
> >> in registers.  64-bit structs may or may not.
> >>
> >> The main advantage of structs is that it's impossible to mismatch the
> >> parameter order.  That even trumps readability in my opinion.
> >>
> >> I'm ambivalent, but I wouldn't mind at all using structs.
> >
> > Thanks for clarifying that Paolo.
> >
> > Yes, the manual bit masking and shifting is easier to get wrong.
> > The struct also has stronger type checking in a way, as you cant OR in literals
> > that are out of bounds. (IIRC GCC will even warn you for free).
> > The struct is also easy to extend if we ever run out of bits in the uint64_t.
> >
> > Peter, would you consider switching to struct or are you still convinced
> > of the pure uint64_t approach?
> 
> OK, having thought about this I'm willing to take the struct-and-bitfields
> approach. My preferences are somewhat based on habit and also on some
> of Linus' rants about bitfields for kernel use [eg
> http://yarchive.net/comp/linux/bitfields.html], but I think we are
> not going to hit any of the problem cases (notably, we don't care
> about the arrangement of the bitfields within the word, we aren't
> trying to have bitfields and locks/volatile/atomic info shared in
> one struct, and we don't have a particular need to test multiple
> bits at once).
> 
> I'll change over to structs for v2.

Awesome, thanks!