Re: [Qemu-devel] [PATCH] block/dmg: make it modular if using additional library

[Markus Armbruster <armbru@redhat.com>]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 10.03.2015 um 10:17 hat Fam Zheng geschrieben:
>> On Tue, 03/10 09:50, Kevin Wolf wrote:
>> > Am 10.03.2015 um 08:06 hat Michael Tokarev geschrieben:
>> > > block/dmg can use additional library (libbz2) to read
>> > > bzip2-compressed files.  Make the block driver to be
>> > > a module if libbz2 support is requested, to avoid extra
>> > > library dependency by default.
>> > > 
>> > > Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
>> > 
>> > First of all: I don't think this is suitable for trivial. The actual
>> > code change might be small, but the change in behaviour is important and
>> > needs discussion.
>> > 
>> > > This might be questionable, to make the thing to be either
>> > > module or built-in depending on build environment, so a
>> > > better idea may be to make it modular unconditionally.
>> > > This block device format isn't used often.
>> > 
>> > Yes, I'm concerned that making it conditional might be a bit surprising.
>> > I'd like to hear some more opinions before applying this.
>> 
>> I don't see the advantage over making it an unconditional module - condition
>> only makes it a bit more complicated.
>> 
>> > 
>> > Also, should we consider making some more rarely used image formats
>> > modules even if they don't pull in external dependencies?
>> 
>> Sounds reasonable to me. Is the intention to reduce binary size?

Fair argument, but not a paricularly weighty one.  The unused code never
gets paged in, mostly, and isn't particularly large to begin with.

> Yes, that and also that it allows compiling out some drivers without
> having to mess with the Makefiles. You just don't install all of them.

Second best solution of the configuration management problem "select a
subset of the available block drivers", good enough when compiling the
unused ones isn't bothersome.  But the best solution is still
configuration management capable of disabling optional components.

> Related to that, Peter also mentioned that you (the user, not developer
> or packager) could simply disable a single driver, for example as a
> temporary hotfix in the case of security problems in a block driver.
> That would actually be an argument for making _all_ drivers modules.

And pretty much every other optional component.

For me, avoiding bothersome dependencies is a strong practical argument
for making a something a loadable module.  Other benefits of loadable
modules presented so far seem pretty negligible to me.  If you want
them, no objection from me, as long as the cost is similarly negligible,
additional complexity for developers, packagers and users in particular.