On 10/15/2015 06:45 AM, Sage Weil wrote:
On Thu, 15 Oct 2015, Mykola Golub wrote:
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.
This is my favorite option too.
Having a str and int variant seems like the best path to me. Maybe int64
though, so that signed values are possible?
Don't think we need any signed values currently. It doesn't cause any
ABI problems to add signed ints or other types later, since it'll
already be overloaded in C++, and for C they need to be new functions
anyway.
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);
Sounds good to me.
Josh
--
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
