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