From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StcgC-0002GB-4n for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:49:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Stcg6-0000pD-GF for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:49:28 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:32992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Stcg6-0000p3-9O for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:49:22 -0400 Received: by bkcji1 with SMTP id ji1so5218557bkc.4 for ; Tue, 24 Jul 2012 03:49:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <500DAEFF.7060708@redhat.com> References: <1342785709-3152-1-git-send-email-stefanha@linux.vnet.ibm.com> <1342785709-3152-7-git-send-email-stefanha@linux.vnet.ibm.com> <500DAEFF.7060708@redhat.com> Date: Tue, 24 Jul 2012 11:49:21 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH 06/16] net: Convert qdev_prop_vlan to peer with hub List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Paolo Bonzini , Zhi Yong Wu , Stefan Hajnoczi , Zhi Yong Wu , qemu-devel@nongnu.org On Mon, Jul 23, 2012 at 9:07 PM, Laszlo Ersek wrote: > On 07/20/12 14:01, Stefan Hajnoczi wrote: > >> @@ -638,11 +642,17 @@ static void get_vlan(Object *obj, Visitor *v, void *opaque, >> { >> DeviceState *dev = DEVICE(obj); >> Property *prop = opaque; >> - VLANState **ptr = qdev_get_prop_ptr(dev, prop); >> - int64_t id; >> + VLANClientState **ptr = qdev_get_prop_ptr(dev, prop); >> + int64_t id = -1; >> >> - id = *ptr ? (*ptr)->id : -1; >> - visit_type_int64(v, &id, name, errp); >> + if (*ptr) { >> + unsigned int hub_id; >> + if (!net_hub_id_for_client(*ptr, &hub_id)) { >> + id = (int64_t)hub_id; >> + } >> + } >> + >> + visit_type_int(v, &id, name, errp); >> } > > Should we use uint32 here? (No particular reason, just for "cleanliness" > or whatever.) As part of the int64_t -> uint32_t type cleanup we can change this. I think it's a safe change to make since no reasonable command-line would make use of the silent 32-bit truncation. Stefan