libuuid vs boost uuid

Commit Message

James Harper Nov. 26, 2013, 5:52 a.m. UTC

> 
> James,
> 
> I'm using uuid.begin()/end() to grab the 16-byte representation of the UUID.
> Did you figure out how to populate a boost::uuid_t from the bytes? In
> particular, I'm referring to FileJournal::decode.
> 
> Actually, I suppose that any Ceph usage of the 16-byte representation should
> be replaced using the Boost serialization of uuid_t?
> 

As I said I haven't actually tested it, apart from that I have librbd working under Windows now ("rbd ls" and "rbd export" both work but I don't know if they actually do anything with uuid's...)

My patch to MStatfsReply.h to make it compile is:


So assuming this actually works, the uuid bytes are accessible as per the above.

James

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Noah Watkins Nov. 26, 2013, 4:44 p.m. UTC | #1

I put up a patch here for review

https://github.com/ceph/ceph/pull/875/files

It seems ok as long as boost doesn’t ever try to change their internal representation, which in this patch we reach in an grab for the 16 octet representation. Why not just grab a copy of libuuid from util-linux and keep it in tree?

On Nov 25, 2013, at 9:52 PM, James Harper <[e-mail]> wrote:

>> 
>> James,
>> 
>> I'm using uuid.begin()/end() to grab the 16-byte representation of the UUID.
>> Did you figure out how to populate a boost::uuid_t from the bytes? In
>> particular, I'm referring to FileJournal::decode.
>> 
>> Actually, I suppose that any Ceph usage of the 16-byte representation should
>> be replaced using the Boost serialization of uuid_t?
>> 
> 
> As I said I haven't actually tested it, apart from that I have librbd working under Windows now ("rbd ls" and "rbd export" both work but I don't know if they actually do anything with uuid's...)
> 
> My patch to MStatfsReply.h to make it compile is:
> 
> diff --git a/src/messages/MStatfsReply.h b/src/messages/MStatfsReply.h
> index 8ceec9c..40a5bdd 100644
> --- a/src/messages/MStatfsReply.h
> +++ b/src/messages/MStatfsReply.h
> @@ -22,7 +22,7 @@ public:
> 
>   MStatfsReply() : Message(CEPH_MSG_STATFS_REPLY) {}
>   MStatfsReply(uuid_d &f, tid_t t, epoch_t epoch) : Message(CEPH_MSG_STATFS_REPLY) {
> -    memcpy(&h.fsid, f.uuid, sizeof(h.fsid));
> +    memcpy(&h.fsid, &f.uuid, sizeof(h.fsid));
>     header.tid = t;
>     h.version = epoch;
>   }
> 
> So assuming this actually works, the uuid bytes are accessible as per the above.
> 
> James
> 

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/src/messages/MStatfsReply.h b/src/messages/MStatfsReply.h
index 8ceec9c..40a5bdd 100644
--- a/src/messages/MStatfsReply.h
+++ b/src/messages/MStatfsReply.h
@@ -22,7 +22,7 @@  public:

   MStatfsReply() : Message(CEPH_MSG_STATFS_REPLY) {}
   MStatfsReply(uuid_d &f, tid_t t, epoch_t epoch) : Message(CEPH_MSG_STATFS_REPLY) {
-    memcpy(&h.fsid, f.uuid, sizeof(h.fsid));
+    memcpy(&h.fsid, &f.uuid, sizeof(h.fsid));
     header.tid = t;
     h.version = epoch;
   }