[Qemu-devel] Re: [PATCH 0/4][RFC] Add module infrastructure to QEMU

[Anthony Liguori <aliguori@us.ibm.com>]

Paul Brook wrote:
> On Monday 11 May 2009, Anthony Liguori wrote:
>   
>> This is the current state of a patch set to introduce a module
>> infrastructure to QEMU.
>>     
>
> I don't think numeric priorities are a good idea. If we have dependencies then 
> we should be dealing with them properly, not hacking round the problem.
>   

The numeric priorities are an implementation detail.  No one should ever 
consume module_init() directly and I should add appropriately scary 
comments to that affect.

The numeric priorities are currently used to implement a simple 
dependency tree with each level of the tree being an integer priority.

We do have dependencies.  I'd like virtio to be a module, and I'd like 
virtio-net, virtio-blk, etc. to be modules.  This gets exposed as 
virtio.c being a bus_init() and virtio-*.c being virtio_init().  We use 
the integer priorities in module.h to express this.

We could get fancier and have explicit dependencies by name or something 
like that.  I'm not sure I think it's worth getting this complex though.

> Also, there's no reason to have destructors. The init function can register 
> these at runtime.
>   

I don't feel strongly here.

The one case I think it could prove useful is that a number of things 
require atexit functions today.  I think it would be good to use 
destructors to make these more standardized.  Also, deregistering 
components has the advantage of making valgrind much happier.

We don't deregister the block drivers in this patch series, but I can 
certainly add it.

>>  2) Switch to using dynamic shared libraries.  This has the benefit of
>> reducing the QEMU install size.  This is attractive except for the fact
>> that creating dynamic shared libraries across multiple host architectures
>> is a pain.
>>     
>
> In practice I'd expect the shared library overhead (both disk and RAM) to be 
> significantly larger than the saving form omitting a few devices. As you said 
> before, if we're not using something, why build it in the first place?
>
> There's also the issue that shared libraries imply it's OK for third parties 
> to ship binary plugins.
>   

I'm strictly talking about libqemu_common.a and libqemu_user.a.  
However, I really don't want to do shared libraries in the absence of 
automake because shared libraries require a lot of per-platform foo to 
create.

I'm happy ruling this out.

Regards,

Anthony Liguori

> Paul
>   


-- 
Regards,

Anthony Liguori