qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Support for loading devices as dynamic librarie


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH] Support for loading devices as dynamic libraries
Date: Sat, 25 Aug 2012 19:18:11 +0100

On Sat, Aug 25, 2012 at 6:06 PM, Dominik Żeromski <address@hidden> wrote:
> 2012/8/25 Stefan Hajnoczi <address@hidden>
>>
>> On Sat, Aug 25, 2012 at 12:10 PM, Dominik Żeromski <address@hidden>
>> wrote:
>> > Adding support for loading DSO with -device option.
>> >
>> > Example Makefile for out of tree modules:
>>
>> QEMU does not have a stable ABI for devices.  There is a lot of device
>> model refactoring happening right now for multithreaded MMIO/PIO
>> dispatch and taking advantage of QEMU Object Model.  A stable ABI
>> hinders those kinds of improvements.
>>
>> Send device model patches upstream.  That way you avoid the
>> maintenance overhead of out-of-tree modules and the QEMU community
>> doesn't need to provide a stable ABI.
>>
>
> I think that QEMU is a great tool, not only for server virtualization
> but also for embedded software and hardware development.
>
> I agree that it would be hard to maintain stable ABI, but this is a
> usability feature for device developers, not QEMU developers. I can
> imagine use cases where one team works on a hardware emulator and
> wants to share it with driver team. Driver team doesn't care about how
> QEMU works, how to configure, compile it and then use it. They
> probably use qemu-kvm and libvirt provided by some Linux distribution.
> The distro qemu-kvm does not change much so it wouldn't be a problem
> for emulator team to fix eventual ABI problems. Distributing device as
> dynamic library is simply easier for both teams.

The hardware team can provide a qemu-custom-board binary instead of a
bunch of .so files to the driver team.  That way the whole emulator
can be tested and will never have ABI issues.  Device model plugins
don't improve this scenario.

Stefan



reply via email to

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