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

[Kevin Wolf]

Am 10.03.2015 um 14:24 hat Markus Armbruster geschrieben:
> Kevin Wolf <address@hidden> 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 <address@hidden>
> >> > 
> >> > 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.

Yes. Though as far as I know, nobody is currently working on that.

> > 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.

I don't really have a strong opinion either way. I agree that the
benefits wouldn't be huge, but then, it would be easy to do and I
haven't heard yet of any drawbacks either. There may well be some that
I'm not aware of, that's why I'm asking.

Kevin