Hi Luiz, On Mon, Feb 21, 2011, Luiz Augusto von Dentz wrote: > > Just throwing my own bits on this: I think making the internal > > representation for uuid_t consistent is important to avoid bugs when > > handling the different UUID types. > > > > currently uuid_t stores 16/32-bit uuids and 128-bit uuid differently. > > The problem is not the internal representation, but things like this: > > - sdp_uuid128_create(&svclass_uuid, SYNCMLC_UUID); > + ntoh128(SYNCMLC_UUID, &h128); > + sdp_uuid128_create(&svclass_uuid, &h128); > > This means the API has changed, it now takes host order where it used > to be network order. We could have a new function e.g. > sdp_uuid128h_create to handle such cases and not break existing > applications using this API. In this particular case the prefix sdp_ already implies that this is for SDP and shouldn't be used in other code. I think what makes sense (and Marcel supported it in IRC) is to a new bt_uuid_t struct and bt_uuid_* helper functions which internally store everything in host byte order. Then in the first phase we can make the ATT code use the new API and later in a second phase start converting existing SDP code to use it. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
