Re: CEPH_RBD_API: options on image create

[Mykola Golub <mgolub@mirantis.com>]

On Thu, Oct 15, 2015 at 08:47:58AM -0400, Jason Dillaman wrote:
> > 
> > But we don't need them to match between different platforms, no? Is
> > linking 64bit code with 32bit possible (supported)?
> > 
> > Also, for this particular (char*) case, length would actually be the
> > length of the string, not the pointer length. From my example:
> > 
> > const char* journal_object_pool = "journal";
> > r = rbd_image_options_set(opts, RBD_OPTION_JOURNAL_OBJECT_POOL,
> >                           journal_object_pool, strlen(journal_object_pool) +
> >                           1);
> > 
> 
> My original example was a string of length 4 vs a 4-byte int, but
> you said you were thinking of sizeof(type) instead.  I think this
> style of interface is great if you need to pass any arbitrary data
> along, but will we ever expect to pass along anything besides a
> string or an (u)int(32/64)?

I don't know, sure you have much more experience here, so if you
hardly expect other types in future, I would be rather then for
rbd_image_options_set_{uint64,str}() functions.

> On the flip-side, what will the C++ interface look like?  An
> equivalent API would imply passing a boost::any.  While certainly
> future-proof, something about that doesn't sit right with me as an
> API.  I think I would lean more towards something like xyz_set(const
> std::string&), xyz_set(uint64_t), et al.

For C++ I was also thinking about xyz_set(const std::string&),
xyz_set(uint64_t) variants, i.e:

int rbd::Image::options::set(int optname, const std::string& val);
int rbd::Image::options::set(int optname, uint64_t val);
...

-- 
Mykola Golub