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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
