From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIg1T-00068m-Q7 for qemu-devel@nongnu.org; Tue, 25 Oct 2011 08:22:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIg1N-0008KV-A7 for qemu-devel@nongnu.org; Tue, 25 Oct 2011 08:22:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIg1N-0008KM-1j for qemu-devel@nongnu.org; Tue, 25 Oct 2011 08:22:21 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9PCMK6X008340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Oct 2011 08:22:20 -0400 Date: Tue, 25 Oct 2011 14:19:33 +0200 From: Alon Levy Message-ID: <20111025121933.GF3490@bow> References: <1319457739-14562-1-git-send-email-alevy@redhat.com> <1319457739-14562-4-git-send-email-alevy@redhat.com> <4EA58393.1040901@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA58393.1040901@redhat.com> Subject: Re: [Qemu-devel] [PATCH 3/5] qxl: support concurrent async commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, mlureau@redhat.com, armbru@redhat.com, lcapitulino@redhat.com On Mon, Oct 24, 2011 at 05:26:11PM +0200, Gerd Hoffmann wrote: > Hi, > > > +SpiceAsyncCommand *push_spice_async_command(PCIQXLDevice *qxl, > > + uint32_t async_io, int size) > > > +/* caller must call g_free */ > > +static SpiceAsyncCommand *pop_spice_async_command(PCIQXLDevice *qxl, > > + uint64_t cookie) > > +{ > > push/pop naming implies stack-like operation, which isn't true though. > pop will lookup by cookie. Also an explicit release function would be > good (list unlink and g_free call can go there). > > Maybe have spice_async_cmd_{alloc,lookup,free} ? > Will do. > Have you considered passing down a SpiceAsyncCommand pointer instead of > the cookie value everywhere? Seems to be a bit cleaner and more > future-proof to me. Not sure it buys us much in practice though, so > maybe it isn't worth the trouble. > That would still require casting, since we want to ensure we can later support 32 bit architectures, so the cookie size of uint64_t will remain. I guess I'll do it. > cheers, > Gerd