On 06.05.20 19:13, Kevin Wolf wrote:
> Am 18.02.2020 um 13:42 hat Max Reitz geschrieben:
>> These calls have no real use for the child role yet, but it will not
>> harm to give one.
>>
>> Notably, the bdrv_root_attach_child() call in blockjob.c is left
>> unmodified because there is not much the generic BlockJob object wants
>> from its children.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> Reviewed-by: Eric Blake <eblake@redhat.com>
> 
>> diff --git a/block/vvfat.c b/block/vvfat.c
>> index 8f4ff5a97e..d4f4218924 100644
>> --- a/block/vvfat.c
>> +++ b/block/vvfat.c
>> @@ -3186,7 +3186,7 @@ static int enable_write_target(BlockDriverState *bs, Error **errp)
>>      options = qdict_new();
>>      qdict_put_str(options, "write-target.driver", "qcow");
>>      s->qcow = bdrv_open_child(s->qcow_filename, options, "write-target", bs,
>> -                              &child_vvfat_qcow, 0, false, errp);
>> +                              &child_vvfat_qcow, BDRV_CHILD_DATA, false, errp);
> 
> Doesn't it contain metadata, too?

Aw, I don’t know...  This is vvfat, I don’t want to know.

Do you mean metadata beyond the filesystem structures?  Are those
structures data or metadata in this context?  Does it even matter?

I suppose I just don’t want to think about all of that, and the simplest
way to do it is to indeed pass METADATA, too.

Max