Re: [Qemu-devel] [PATCH v4 17/32] blockdev: Separate bochs probe from its driver

[Colin Lord]

On 07/18/2016 12:28 PM, Max Reitz wrote:
> On 14.07.2016 21:03, Colin Lord wrote:
>> Modifies the bochs probe to return the format name as well as the
>> score as the final step of separating the probe function from the
>> driver. This keeps the probe completely independent of the driver,
>> making future modularization easier to accomplish. Returning the format
>> name as well as the score allows the score to be correlated to the
>> driver without the probe function needing to be part of the driver.
>>
>> Signed-off-by: Colin Lord <address@hidden>
>> ---
>>  block.c               | 20 ++++++++++++++++++++
>>  block/bochs-probe.c   | 25 ++++++++++++++++---------
>>  block/bochs.c         |  1 -
>>  include/block/probe.h |  3 ++-
>>  4 files changed, 38 insertions(+), 11 deletions(-)
>>
>> diff --git a/block.c b/block.c
>> index 3a0dc19..b16f8cf 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -25,6 +25,7 @@
>>  #include "trace.h"
>>  #include "block/block_int.h"
>>  #include "block/blockjob.h"
>> +#include "block/probe.h"
>>  #include "qemu/error-report.h"
>>  #include "module_block.h"
>>  #include "qemu/module.h"
>> @@ -56,6 +57,13 @@
>>  
>>  #define NOT_DONE 0x7fffffff /* used while emulated sync operation in 
>> progress */
>>  
>> +typedef const char *BdrvProbeFunc(const uint8_t *buf, int buf_size,
>> +                                  const char *filename, int *score);
>> +
>> +static BdrvProbeFunc *format_probes[] = {
>> +    bdrv_bochs_probe,
>> +};
>> +
> 
> I really can't convince you of my "struct concept", can I? :-)
> 
> Unless maybe I can:
> 
> Reviewed-by: Max Reitz <address@hidden>
> 
If you really want me to I could go back and change it. I do have to
agree that it's a little odd to be returning the same string every time,
but it also strikes me as pretty weird if the probing functions
themselves can't even be associated with their drivers without the help
of another struct. It doesn't seem quite right to me if the functions
can't be used independently of the struct containing the mappings.
Technically of course they could still be used, but without the mappings
they are practically indistinguishable from each other so they're
basically useless.

Since both options seem to have their own quirks, I'm not too excited to
go back and edit all the patches only to end up with something I see as
equally weird. But again, if you (or others) really want me to change
it, or show me why having a bunch of indistinguishable probing functions
isn't as weird as I think, I could certainly do so.

Colin