qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v2 21/36] rbd: Pass BlockdevOptionsRbd to qemu_r


From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH v2 21/36] rbd: Pass BlockdevOptionsRbd to qemu_rbd_connect()
Date: Fri, 23 Feb 2018 17:19:51 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

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 <address@hidden>

> > -    *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.

Kevin

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]