Hi, On Mon, Feb 21, 2011 at 10:14 AM, Claudio Takahasi <claudio.takahasi@xxxxxxxxxxxxx> wrote: > On Sat, Feb 19, 2011 at 6:07 PM, Luiz Augusto von Dentz >> IMO it would be easier to have specific functions for uuid128 that can >> take data in host order, so that we don't break existing API. Note >> that the internal representation could be changed to host order, that >> is fine, but then you convert the existing function to do the >> conversion internally without breaking compatibility. > > Yes, it is easier. It will be necessary to add a function to convert > from little endian to big endian for ATT when the data is received. > I am not changing the API, it changes only the internal > representation(to host order) of the UUID128 values. 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. Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- 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
