uuid_t and bt_uuid_t

uuid_t and bt_uuid_t

[Brian Gix]

Can anybody tell me why we have to almost-but-not-quite equivalent 
storage mechanisms for UUIDs in (user-space) BlueZ?  This is accompanied 
by multiple sets of utilities as well.  It looks like one is targeting 
SDP and one isn't.  However, I need to occasionally translate from one 
form to the other.

They both include a "type" which is a u8 in one instance, and an enum in 
the other.  And then they both include a union for the u16, u32 and u128.

Is one suppose to be in network order, and the other native?  I can't 
tell just from looking at the various usages.

-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

Re: uuid_t and bt_uuid_t

[Johan Hedberg]

Hi Brian,

On Wed, Jan 18, 2012, Brian Gix wrote:
> Can anybody tell me why we have to almost-but-not-quite equivalent
> storage mechanisms for UUIDs in (user-space) BlueZ?  This is
> accompanied by multiple sets of utilities as well.  It looks like
> one is targeting SDP and one isn't.  However, I need to occasionally
> translate from one form to the other.
> 
> They both include a "type" which is a u8 in one instance, and an
> enum in the other.  And then they both include a union for the u16,
> u32 and u128.
> 
> Is one suppose to be in network order, and the other native?  I
> can't tell just from looking at the various usages.

The intention is to eventually move all code over to bt_uuid_t and get
rid of uuid_t. The problem with uuid_t is that it uses different byte
order depending on the UUID length. E.g. 16 and 32 are stored in host
byte order while 128 is stored in SDP byte order (big endian). The
purpose if bt_uuid_t it to have a type that's always in the host byte
order and thereby eliminate any confusion when using UUIDs with
protocols of different byte order requirements (e.g. SDP is big-endian
but ATT is little endian).

Johan