On 19.07.2016 12:54, Paolo Bonzini wrote: > > > On 14/07/2016 21:02, Colin Lord wrote: >> Here's v4 of the modularization series. Things that have changed since >> v3 include: >> >> - Fix indentation of the generated header file module_block.h >> - Drivers and probe functions are now all located in the block/ >> directory, rather than being split between block/ and block/probe/. In >> addition the header files for each probe/driver pair are in the block/ >> directory, not the include/block/driver/ directory (which no longer >> exists). >> - Since the probe files are in block/ now, they follow the naming >> pattern of format-probe.c >> - Renamed crypto probe file to be crypto-probe.c, luks is no longer in >> the filename >> - Fixed formatting of parallels_probe() function header >> - Enforced consistent naming convention for the probe functions. They >> now follow the pattern bdrv_format_probe(). > > It's still not clear to me why probes need to be separate for drivers > that (presumably) will never be modularized.
For completeness' sake, my stance on the issue can be summarized as "Why not?". The patches exist, so "Someone would need to do it" is not an argument anymore. Daniel said the separation of the probing functions introduced by this series would break the block drivers' "self-containedness", but I'm not sure all block drivers are contained in a single file, if that is what he meant by it. qcow2 and vhdx aren't, and I never had any problem with that. Maybe he was referring to the file placement discussion we had some weeks ago. Obviously we didn't end up with a unanimous consensus, so intuitively I'd say sidestepping this issue would be worth something. But it really isn't. In my very personal opinion, letting dissent over coding style get in the way of a functional issue is not really something we should do. Also, I think it's actually debatable whether the probing function belongs to a block driver. One could argue that all the probing functions in theory belong to a virtual block driver that we haven't given a name to yet, but that is selected by not specifying any driver. That virtual driver then does nothing but replace itself by the probed one. As far as I'm aware, we've always planned to give that virtual block driver a name (such as "probe-format") in the future. From that point of view, one could argue that pulling out the probe functions from the block drivers is actually the right thing to do, independently of modularization, because the probing functions are actually not part of the drivers themselves. So I can't see a strong argument for not modularizing the format block drivers, but in turn I don't have a strong argument for doing so either. Therefore: Why not? :-) Max
signature.asc
Description: OpenPGP digital signature