From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:38245)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1TLbYt-0002Lh-O5
	for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:17:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1TLbYk-0006dM-7g
	for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:17:35 -0400
Received: from mail-oa0-f45.google.com ([209.85.219.45]:62536)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1TLbYk-0006cz-2q
	for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:17:26 -0400
Received: by mail-oa0-f45.google.com with SMTP id i18so1371267oag.4
	for <qemu-devel@nongnu.org>; Tue, 09 Oct 2012 08:17:25 -0700 (PDT)
From: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <506DA076.3080501@redhat.com>
References: <1349280245-16341-1-git-send-email-avi@redhat.com>
	<1349280245-16341-20-git-send-email-avi@redhat.com>
	<87ehleiav7.fsf@codemonkey.ws> <506DA076.3080501@redhat.com>
Date: Tue, 09 Oct 2012 10:17:21 -0500
Message-ID: <87zk3vlloe.fsf@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Qemu-devel] [RFC v1 19/22] memory: per-AddressSpace dispatch
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, liu ping fan <qemulist@gmail.com>

Avi Kivity <avi@redhat.com> writes:

> On 10/04/2012 04:13 PM, Anthony Liguori wrote:
>>>  
>>> +void address_space_init_dispatch(AddressSpace *as)
>>> +{
>>> +    AddressSpaceDispatch *d = g_new(AddressSpaceDispatch, 1);
>>> +
>>> +    d->phys_map  = (PhysPageEntry) { .ptr = PHYS_MAP_NODE_NIL, .is_leaf = 0 };
>>> +    d->listener = (MemoryListener) {
>>> +        MEMORY_LISTENER_DEFAULT_OPS,
>>> +        .begin = mem_begin,
>>> +        .region_add = mem_add,
>>> +        .region_nop = mem_add,
>>> +        .priority = 0,
>>> +    };
>> 
>> I see you've become fond of this extension :-)
>
> It's not an extension.
>
>> I'd personally avoid it...  You're typing more than you need to.
>
> Don't see why, it seems to me to be a direct way of specifying what you
> want.  You can read it literally as "d->phys_map is assigned a
> PhysPageEntry structure with ptr = this and is_leaf = that.
>
> The alternatives are:
>
>    memset(&d->phys_map, 0, sizeof(d->phys_map);
>    d->phys_map.ptr = PHYS_MAP_NODE_NIL;
>    d->phys_map.is_leaf = 0;
>
> or
>
>    PhysPageEntry tmp = { .ptr = PHYS_MAP_NODE_NIL, .is_leaf = 0 };
>
>    d->phys_map = tmp;
>
> I find both of these less appealing than the original.

I don't really care about the use of struct literals...

You are typing more than you need to.  The bit that I think really
matters is using zero-initialization as the default vs. using a macro.

Regards,

Anthony Liguori

>
> -- 
> error compiling committee.c: too many arguments to function