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

[Peter Maydell]

On 10 April 2015 at 03:07, Edgar E. Iglesias <address@hidden> 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.

thanks
-- PMM