From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:35913)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1RLgSy-0008Pg-Hu
	for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:27:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1RLgSx-0006Ms-4n
	for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:27:16 -0400
Received: from cantor2.suse.de ([195.135.220.15]:53265 helo=mx2.suse.de)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1RLgSw-0006Mo-To
	for qemu-devel@nongnu.org; Wed, 02 Nov 2011 15:27:15 -0400
Message-ID: <4EB1998E.1000502@suse.de>
Date: Wed, 02 Nov 2011 20:27:10 +0100
From: Alexander Graf <agraf@suse.de>
MIME-Version: 1.0
References: <4639B135-B96A-43A0-B4FA-6DDCBE3FBA92@suse.de>	<CAFEAcA9jh5E5WQH6YwAX1HBKg8W5NB5aR8kmTTz2h6wdRhc0KA@mail.gmail.com>	<4EB18172.1020905@adacore.com>	<4EB18952.4080403@siemens.com>	<4EB18C13.2030704@codemonkey.ws>	<4EB18D1C.4090000@suse.de>	<4EB18FFF.7010603@siemens.com>	<4EB19053.4050500@suse.de>
	<CAFEAcA9VBdjLDNWxiyRJw2zBK0cP=rGkoLQSg4iiDgeWVzNu+g@mail.gmail.com>
In-Reply-To: <CAFEAcA9VBdjLDNWxiyRJw2zBK0cP=rGkoLQSg4iiDgeWVzNu+g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] GSoC mentor summit QEMU users session
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Fabien Chouteau <chouteau@adacore.com>, "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>

Peter Maydell wrote:
> On 2 November 2011 18:47, Alexander Graf <agraf@suse.de> 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.

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.

Alex