From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LpaCV-0000xk-Fh for qemu-devel@nongnu.org; Thu, 02 Apr 2009 23:36:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LpaCR-0000tz-Qh for qemu-devel@nongnu.org; Thu, 02 Apr 2009 23:36:15 -0400 Received: from [199.232.76.173] (port=48879 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LpaCR-0000th-KS for qemu-devel@nongnu.org; Thu, 02 Apr 2009 23:36:11 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:43628) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LpaCR-0004b6-9M for qemu-devel@nongnu.org; Thu, 02 Apr 2009 23:36:11 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n333bfXY027662 for ; Thu, 2 Apr 2009 23:37:41 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n333a7tX187414 for ; Thu, 2 Apr 2009 23:36:07 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n333YVCd005754 for ; Thu, 2 Apr 2009 23:34:32 -0400 Message-ID: <49D58424.7050605@us.ibm.com> Date: Thu, 02 Apr 2009 22:36:04 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Introduce module API to QEMU References: <1238724755-15929-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org, Paul Brook malc wrote: > Once again ISO/IEC 9899:1990 4.1.2 > I don't see a 4.1.2... Section 4 is "Conformance". > ISO/IEC 9899:1999 7.1.3 > At any rate, I assume you're referring to: > +extern module_init_fn __start_initfuncs[], __stop_initfuncs[]; > +extern module_exit_fn __start_exitfuncs[], __stop_exitfuncs[]; All sections have variable definitions that define their start and stop that are in the form __start_SECTION and __stop_SECTION. The __attribute__((section("initfuncs"), used)) directive adds a new section (if necessary) named initfuncs and the linker will create these variables. If you look closely, the patch doesn't define these variables, it just declares them because they're defined by the linker. So this is exactly the sort of thing that the standard is there to protect :-) Regards, Anthony Liguori