qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 0/3] Dynamic module loading for block drivers


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH v5 0/3] Dynamic module loading for block drivers
Date: Fri, 29 Jul 2016 14:33:36 +0800
User-agent: Mutt/1.6.1 (2016-04-27)

On Mon, 07/25 09:56, Colin Lord wrote:
> >> - Remove dmg from block-obj-m since it is not a target of the
> >>   modularization effort.
> > 
> > Hm, I'm afraid I don't quite understand the reasoning behind this.
> > Intuitively, I'd say "Doesn't matter, it was already modular, so what
> > prevents it from staying that way?"
> > 
> > Is it because the changes to util/module.c in patch 3 break how the dmg
> > module worked, e.g. that it was always implicitly fully loaded on qemu
> > startup if it was available, but now modules are only loaded on request?
> > 
> Yes, that's pretty much it. Previously all the modules would get loaded
> during initialization, but since the third patch adds dynamic loading
> that no longer happens. As we aren't loading format drivers on demand,
> dmg.o should be added to block-obj-y instead of block-obj-m so that it
> doesn't get modularized.

The question should be raised about the extra libbz2 dependency that could be
pulled in to qemu main package again, by this series.  dmg.o was added to
block-obj-m in 5505e8b76 to make it a separate module (and therefore a
downstream package), so that its reference to libbz2, since 6b383c08c, doesn't
add an extra library to the main executable.

Michael can correct me if I'm wrong about that.

For the constructive part.  To prevent the hard dependency, we can probably
extract the BZ2_bzDecompress* part into block/dmg-bz2.so, and use the same
"register" trick as in the SDL series [1] to hook up into dmg_read_chunk().

[1]: https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg06085.html

Fam



reply via email to

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