All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Jeff Cody <jcody@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 5/5] block/rbd: add support for 'mon_host', 'auth_supported' via QAPI
Date: Tue, 28 Feb 2017 16:30:51 +0100	[thread overview]
Message-ID: <87tw7etjro.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20170228144228.GB15696@localhost.localdomain> (Jeff Cody's message of "Tue, 28 Feb 2017 09:42:28 -0500")

Jeff Cody <jcody@redhat.com> writes:

> On Tue, Feb 28, 2017 at 03:34:10PM +0100, Markus Armbruster wrote:
>> Starting with just the QAPI schema.
>> 
>> Jeff Cody <jcody@redhat.com> writes:
>> 
>> > This adds support for three additional options that may be specified
>> > by QAPI in blockdev-add:
>> >
>> >     server: host, port
>> >     auth method: either 'cephx' or 'none'
>> >
>> > The "server" and "auth-supported" QAPI parameters are arrays.  To conform
>> > with the rados API, the array items are join as a single string with a ';'
>> > character as a delimiter when setting the configuration values.
>> >
>> > Signed-off-by: Jeff Cody <jcody@redhat.com>
>> > ---
>> [...]
>> > diff --git a/qapi/block-core.json b/qapi/block-core.json
>> > index f152953..5f74f92 100644
>> > --- a/qapi/block-core.json
>> > +++ b/qapi/block-core.json
>> > @@ -2666,6 +2666,28 @@
>> >              '*header-digest': 'IscsiHeaderDigest',
>> >              '*timeout': 'int' } }
>> >  
>> > +
>> > +##
>> > +# @RbdAuthSupport:
>> > +#
>> > +# An enumeration of RBD auth support
>> > +#
>> > +# Since: 2.9
>> > +##
>> > +{ 'enum': 'RbdAuthSupport',
>> > +  'data': [ 'cephx', 'none' ] }
>> > +
>> > +
>> > +##
>> > +# @RbdAuthMethod:
>> > +#
>> > +# An enumeration of rados auth_supported types
>> > +#
>> > +# Since: 2.9
>> > +##
>> > +{ 'struct': 'RbdAuthMethod',
>> > +  'data': { 'auth': 'RbdAuthSupport' } }
>> > +
>> 
>> Any particular reason for wrapping the enum in a struct?  Do you
>> envisage adding members to the struct?
>>
>
> I am going to admit, mainly it was my frustration with trying to deal with a
> qapi array of just enums in a QDict, and structs was more straightforward.
> What is the best way to parse an array of enums inside a QDict?  Do you need
> to extract the subqdict via qdict_extract_subqdict() still?

I admit I'm not so familiar with the block layer's QObject mangling, and
the helper functions we've grown to support that.

I *am* familiar with QAPI visitors (I better be, I maintain the
subsystem), and they are my preferred tool to go from QObject to C data
structures and back.

The "to C" direction uses a QObject input visitor.  Roughly like this:

    Error *err = NULL;
    Visitor *v;
    QapiType *qapi;

    v = qobject_input_visitor_new(qobj);
    visit_type_QapiType(v, NULL, &qapi, &err);
    visit_free(v);

You now either got an Error object in @err, or a QapiType object in
@qapi.

To free the QapiType:

    qapi_free_QapiType(qapi);

The QapiType for ['RbdAuthSupport'] (i.e. list of enum RbdAuthSupport) is
called RbdAuthSupportList, and should look like this:

    struct RbdAuthSupportList {
        RbdAuthSupportList *next;
        RbdAuthSupport value;
    };

The next thing I have to admit is that I fail to see where you're
dealing "with a qapi array of just enums in a QDict".  Can you help?

>> >  ##
>> >  # @BlockdevOptionsRbd:
>> >  #
>> > @@ -2681,6 +2703,11 @@
>> >  #
>> >  # @user:               #optional Ceph id name.
>> >  #
>> > +# @server:             #optional Monitor host address and port.  This maps
>> > +#                      to the "mon_host" Ceph option.
>> 
>> Suggest something like "Monitor addresses", for consistency with how we
>> document *SocketAddress members elsewhere, and plural to hint at it
>> being a list, not just one.
>> 
>
> OK, thanks.
>
>> > +#
>> > +# @auth-supported:     #optional Authentication supported.
>> > +#
>> >  # @password-secret:    #optional The ID of a QCryptoSecret object providing
>> >  #                      the password for the login.
>> >  #
>> > @@ -2692,6 +2719,8 @@
>> >              '*conf': 'str',
>> >              '*snapshot': 'str',
>> >              '*user': 'str',
>> > +            '*server': ['InetSocketAddress'],
>> > +            '*auth-supported': ['RbdAuthMethod'],
>> >              '*password-secret': 'str' } }
>> >  
>> >  ##

  reply	other threads:[~2017-02-28 15:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28  4:12 [Qemu-devel] [PATCH v3 0/5] RBD: blockdev-add (for 2.9?) Jeff Cody
2017-02-28  4:12 ` [Qemu-devel] [PATCH v3 1/5] block/rbd: don't copy strings in qemu_rbd_next_tok() Jeff Cody
2017-02-28  4:12 ` [Qemu-devel] [PATCH v3 2/5] block/rbd: add all the currently supported runtime_opts Jeff Cody
2017-02-28  4:12 ` [Qemu-devel] [PATCH v3 3/5] block/rbd: parse all options via bdrv_parse_filename Jeff Cody
2017-02-28  4:12 ` [Qemu-devel] [PATCH v3 4/5] block/rbd: add blockdev-add support Jeff Cody
2017-02-28  4:12 ` [Qemu-devel] [PATCH v3 5/5] block/rbd: add support for 'mon_host', 'auth_supported' via QAPI Jeff Cody
2017-02-28 14:34   ` Markus Armbruster
2017-02-28 14:42     ` Jeff Cody
2017-02-28 15:30       ` Markus Armbruster [this message]
2017-02-28 15:07   ` Markus Armbruster
2017-02-28 15:21     ` Jeff Cody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tw7etjro.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=jcody@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.