From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38842 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQKxB-0004bL-F4 for qemu-devel@nongnu.org; Wed, 08 Dec 2010 09:25:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQKxA-000424-Em for qemu-devel@nongnu.org; Wed, 08 Dec 2010 09:25:09 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:40997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQKxA-00041z-6H for qemu-devel@nongnu.org; Wed, 08 Dec 2010 09:25:08 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB8EDQgu030296 for ; Wed, 8 Dec 2010 07:13:26 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB8EP0cg162962 for ; Wed, 8 Dec 2010 07:25:00 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB8EOxGC018912 for ; Wed, 8 Dec 2010 07:25:00 -0700 Message-ID: <4CFF9539.9080706@linux.vnet.ibm.com> Date: Wed, 08 Dec 2010 08:24:57 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][PATCH v5 01/21] Move code related to fd handlers into utility functions References: <1291399402-20366-1-git-send-email-mdroth@linux.vnet.ibm.com> <1291399402-20366-2-git-send-email-mdroth@linux.vnet.ibm.com> <4CFE3738.4010506@redhat.com> <4CFE4928.5000409@linux.vnet.ibm.com> <4CFE4C6B.1010600@redhat.com> <20101208091513.GA5974@stefanha-thinkpad.localdomain> In-Reply-To: <20101208091513.GA5974@stefanha-thinkpad.localdomain> 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: Stefan Hajnoczi Cc: agl@linux.vnet.ibm.com, Jes Sorensen , qemu-devel@nongnu.org, Michael Roth , ryanh@us.ibm.com, abeekhof@redhat.com On 12/08/2010 03:15 AM, Stefan Hajnoczi wrote: > On Tue, Dec 07, 2010 at 04:02:03PM +0100, Jes Sorensen wrote: > >> On 12/07/10 15:48, Michael Roth wrote: >> >>> On 12/07/2010 07:31 AM, Jes Sorensen wrote: >>> >>>> On 12/03/10 19:03, Michael Roth wrote: >>>> I am not happy with this addition of numbers to these functions, it >>>> doesn't tell us why we have a 3 and how it differs from 2. If 3 is >>>> really the backend for implementing 2, maybe it would be better to name >>>> it __qemu_set_fd_handler2() and then have macros/wrappers calling into >>>> it. >>>> >>> That was the initial plan, but qemu_set_fd_handler2() is a back-end of >>> sorts for qemu_set_fd_handler(), so I was just trying to be consistent >>> with the naming. Personally I don't have any objections one way or the >>> other. >>> >> Anything to avoid qemu_set_fd_handler17() at some point. I think using >> __qemu_set_fd_handler() encourages people to modify that code rather >> than copy it. >> > I agree that qemu_set_fd_handler3() could be named something more > meaningful. Unfortunately we can't use __qemu_set_fd_handler() because > the C language standard reserves identifiers that start with double > underscore for the standard library. The Linux kernel gets away with it > because the code is freestanding but that doesn't apply to QEMU. > fdset_set_handler() or: iohandler_set_handler() Take whatever the structure is that represents the global state, convert it's name to lower case, and use that as the prefix. If this were C++, the namespacing would be obvious because you wouldn't have a choice about how to design the namespace ;-) /me ducks Regards, Anthony Liguori > Stefan >