From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Npjap-0002de-5q for qemu-devel@nongnu.org; Thu, 11 Mar 2010 09:42:31 -0500 Received: from [199.232.76.173] (port=55440 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Npjao-0002d6-Pj for qemu-devel@nongnu.org; Thu, 11 Mar 2010 09:42:30 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Npjao-00074l-1l for qemu-devel@nongnu.org; Thu, 11 Mar 2010 09:42:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56216) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Npjan-00074X-D1 for qemu-devel@nongnu.org; Thu, 11 Mar 2010 09:42:29 -0500 Message-ID: <4B990149.8010308@redhat.com> Date: Thu, 11 Mar 2010 16:42:17 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 1/7] Add support for generic notifier lists References: <1268239869-16058-1-git-send-email-aliguori@us.ibm.com> <201003111257.59828.paul@codesourcery.com> <4B98EF51.7040905@redhat.com> <4B98F32B.7070706@redhat.com> <4B98FFF8.3060000@redhat.com> In-Reply-To: <4B98FFF8.3060000@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, Anthony Liguori , Gerd Hoffman , Paul Brook , Luiz Capitulino On 03/11/2010 04:36 PM, Paolo Bonzini wrote: > On 03/11/2010 02:42 PM, Avi Kivity wrote: >> On 03/11/2010 03:25 PM, Paolo Bonzini wrote: >>> I didn't understand the advantage of making QEMUNotifier a >>> struct. Instead of using container_of, reusing QEMUBHFunc (renamed to >>> QEMUCallbackFunc maybe?) in QEMUNotifierNode [...] >>> seems cleaner. You would place the QEMUNotifierNode in VncState in >>> order to do the removal later. >> >> I disagree. container_of() is both a little more type safe, and removes >> the need for an extra pointer and memory object. > > The caller will almost always have an object in which to embed the > > notifier, best to make use of it. > > It doesn't remove the need for an extra memory object. Anthony's > design embeds the Notifier but not the NotifierNode. Indeed, my > design does have an extra pointer (in the NotifierNode, which grows > from 3 to 4 words). Right. Well, it should. > I still don't like container_of much, but maybe I'll grow my > appreciation of it with time. :-) Or grow your dislike of void pointers. -- error compiling committee.c: too many arguments to function