From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36214 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsE1a-0001pF-OI for qemu-devel@nongnu.org; Wed, 23 Feb 2011 07:41:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsE1Z-0006Ww-GP for qemu-devel@nongnu.org; Wed, 23 Feb 2011 07:40:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsE1Z-0006Vw-6f for qemu-devel@nongnu.org; Wed, 23 Feb 2011 07:40:57 -0500 Message-ID: <4D650051.5070709@redhat.com> Date: Wed, 23 Feb 2011 14:40:49 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/7] iohandlers: Introduce a new API References: <3d41a2ca603b8132e2496976e89fca09fc246683.1298369272.git.amit.shah@redhat.com> <4D63B9E2.5060201@redhat.com> <4D63CF82.8060006@codemonkey.ws> <4D63E299.8070808@redhat.com> <4D63FEA4.1000002@codemonkey.ws> In-Reply-To: <4D63FEA4.1000002@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , qemu list , Gerd Hoffmann On 02/22/2011 08:21 PM, Anthony Liguori wrote: > On 02/22/2011 10:21 AM, Avi Kivity wrote: >> On 02/22/2011 05:00 PM, Anthony Liguori wrote: >>>> >>>> Drop the opaque, instead put the IOHandler in there (or maybe the >>>> CharDev?) and use container_of(). >>> >>> >>> You know, I'm not there that this is automatically better. >> >> Why not? One less unsafe cast. > > It turns out there are a lot of cases in QEMU where there isn't an > obvious data structure to piggy back on. Examples? In that case you can always make a structure with a void * and a IOHandler, and you get your opaque. But I don't really see how it can happen, the void * always points to a structure (or is ignored if there's a static instance), and you can add that IOHandler to the structure. > >>> Why is there an IOHandler and an IOEventHandler argument for init? > > So wouldn't you set the IOEventHandler directly in the IOHandler as > part of initialization? IOW: > > struct MyDevice { > IOHandler iohandler; > }; > > iohandler.func = my_io_function; > io_handler_init(&iohandler, fd, event_mask); > > That's the paradigm I'm used to at least. You mean instead of passing .func to io_handler_init()? I slightly prefer my version (less chance to forget the assignment) but I'm okay with either. -- error compiling committee.c: too many arguments to function