qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] GSoC mentor summit QEMU users session


From: Anthony Liguori
Subject: Re: [Qemu-devel] GSoC mentor summit QEMU users session
Date: Wed, 02 Nov 2011 14:35:49 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 11/02/2011 02:27 PM, Alexander Graf wrote:
Peter Maydell wrote:
On 2 November 2011 18:47, Alexander Graf<address@hidden>  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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]