On 2018-02-23 17:19, Kevin Wolf wrote:
> Am 23.02.2018 um 00:25 hat Max Reitz geschrieben:
>> On 2018-02-21 14:53, Kevin Wolf wrote:
>>> With the conversion to a QAPI options object, the function is now
>>> prepared to be used in a .bdrv_co_create implementation.
>>>
>>> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> 
>>> -    *s_snap = g_strdup(snap);
>>> -    *s_image_name = g_strdup(image_name);
>>> +    *s_snap = g_strdup(opts->snapshot);
>>> +    *s_image_name = g_strdup(opts->image);
>>>  
>>>      /* try default location when conf=NULL, but ignore failure */
>>> -    r = rados_conf_read_file(*cluster, conf);
>>> -    if (conf && r < 0) {
>>> -        error_setg_errno(errp, -r, "error reading conf file %s", conf);
>>> +    r = rados_conf_read_file(*cluster, opts->conf);
>>> +    if (opts->has_conf && r < 0) {
>>
>> Reading opts->conf without knowing whether opts->has_conf is true is a
>> bit weird.  Would you mind "s->has_conf ? opts->conf : NULL" for the
>> rados_conf_read() call?
>>
>> On that thought, opts->snapshot and opts->user are optional, too.  Are
>> they guaranteed to be NULL if they haven't been specified?  Should we
>> guard those accesses with opts->has_* queries, too?
> 
> These days, both the QMP marshalling code (for the outermost struct when
> called from x-blockdev-create) and the input visitor (for nested structs
> and non-QMP callers) initialise the objects with {0} and g_malloc0().
> 
> I think Markus once told me that I shouldn't do pointless has_* checks
> any more in QMP commands, so I intentionally did the same here.

I'm a bit cautious because of non-zero defaults (like sslverify in the
ssh driver), but as long as you're aware...

Max