[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 01/14] memory: Define API for MemoryRegionOps to
From: |
Edgar E. Iglesias |
Subject: |
Re: [Qemu-devel] [PATCH 01/14] memory: Define API for MemoryRegionOps to take attrs and return status |
Date: |
Sat, 11 Apr 2015 20:27:10 +1000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Apr 10, 2015 at 03:51:07PM +0100, Peter Maydell wrote:
> 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.
Awesome, thanks!
[Qemu-devel] [PATCH 05/14] exec.c: Convert subpage memory ops to _with_attrs, Peter Maydell, 2015/04/07
[Qemu-devel] [PATCH 08/14] Switch non-CPU callers from ld/st*_phys to address_space_ld/st*, Peter Maydell, 2015/04/07
[Qemu-devel] [PATCH 03/14] Make CPU iotlb a structure rather than a plain hwaddr, Peter Maydell, 2015/04/07
Re: [Qemu-devel] [PATCH 00/14] Add memory attributes and use them in ARM, Edgar E. Iglesias, 2015/04/09