From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLgbL-0001il-80 for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:35:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLgbJ-0008Rc-T3 for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:35:55 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:34361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLgbJ-0008RT-Nh for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:35:53 -0400 Received: by ggnr5 with SMTP id r5so553946ggn.4 for ; Wed, 02 Nov 2011 12:35:52 -0700 (PDT) Message-ID: <4EB19B95.60405@codemonkey.ws> Date: Wed, 02 Nov 2011 14:35:49 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4639B135-B96A-43A0-B4FA-6DDCBE3FBA92@suse.de> <4EB18172.1020905@adacore.com> <4EB18952.4080403@siemens.com> <4EB18C13.2030704@codemonkey.ws> <4EB18D1C.4090000@suse.de> <4EB18FFF.7010603@siemens.com> <4EB19053.4050500@suse.de> <4EB1998E.1000502@suse.de> In-Reply-To: <4EB1998E.1000502@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] GSoC mentor summit QEMU users session List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , "qemu-devel@nongnu.org Developers" , Fabien Chouteau , Jan Kiszka On 11/02/2011 02:27 PM, Alexander Graf wrote: > Peter Maydell wrote: >> On 2 November 2011 18:47, Alexander Graf wrote: >> >>> Jan Kiszka wrote: >>> >>>> We should also be able to establish an EXPORT_SYMBOL concept, ie. only >>>> export those functions that are supposed to be part of a component API. >>>> Will be some work initially, but should be off long term, both to QEMU >>>> in maintaining stable APIs and to external components in using the >>>> proper ones. >>>> >> >> >>> Yes. IOW, let's go down the same road as Linux. It works well for them, >>> why not for us? >>> >> >> I'd rather see us have a decent usable API for implementing devices >> *inside* the QEMU source tree before we start thinking about having >> one for devices outside the tree... >> > Right. That's exactly what Linux does. On Linux, you have EXPORT_SYMBOL > and EXPORT_SYMBOL_GPL. The former is considered reasonably stable. The > latter can change even in minor revisions. No... neither are stable. The difference is historical and has to do with licensing, not stability. > So the obvious thing to do would be to export everything, but mark it > unstable and then mark things stable as we go in and actually consider > them stable. And only consider them stable for a limited time. For the record, I'm opposed to ever having a stable plugin API. We aren't a closed source product. If people want to have to keep up with our changing internal interfaces, they can get their code merged upstream. Regards, Anthony Liguori > Alex > >