Re: [PATCH 0/4] modules: add support for target-specific modules.

[Claudio Fontana <cfontana@suse.de>]

On 6/17/21 7:37 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>>>> However, please correct me if I'm wrong, I understand that an accelerator as a 
>>>> module will add an overhead that some user won't be willing to pay. So, give 
>>>> them the option to have built-in accelerators seems a good idea.
>>>
>>> Modules add some overhead, yes, and there are surely use-cases where you
>>
>> Where do we expect the overhead to be, and of which nature?
> 
> The dynamic linking needed then when loading the module adds a bit of
> overhead (compared to static linked code).  Increases qemu start time
> a bit.
> 
> On the other hand the start overhead can be reduced by modules,
> specifically for the case that a module depends on shared libraries and
> is *not* needed.  With for example gtk being modular the gtk shared
> libraries (plus indirect dependencies like pango, cairo etc) are only
> loaded when you actually use gtk, whereas a non-modular build would load
> them no matter what.

Interesting observation.

> 
> The code reorganization needed for modularization can add some overhead
> too, when using function pointers instead of direct calls for example
> (see QemuSpiceOps).  That overhead doesn't go away when you do a
> non-modular build though ...
> 
> take care,
>   Gerd
> 

Do we need to be able to unload modules that we previously loaded? Or is this not a realistic requirement?

Thanks,

Claudio