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

[Blue Swirl]

On Wed, Nov 2, 2011 at 19:35, Anthony Liguori <address@hidden> wrote:
> 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.

Fully agree. I don't even think there can be any benefit for us from a
plugin system, only API/ABI legacy maintenance effort and limitations
to architectural changes. All benefits are external.

There are other useful paths available for external users, QAPI, QMP,
GDBstub, maybe also instrumentation in the future.

Perhaps we could add a 'contrib' directory where new stuff could be
added easily to make life outside better. It could also be used to
clean up bitrotten devices and functionality from core. Marking things
with deprecated attributes or something like CONFIG_EXPERIMENTAL in
Linux could also help.

> Regards,
>
> Anthony Liguori
>
>> Alex
>>
>>
>
>
>