Re: [Qemu-block] [PATCH v4 00/32] Dynamic module loading for block drivers

[Max Reitz]

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