Hi Siarhei, > > The messy part here is we let the caller specify the byte order of the > > array. It would simplify a lot to standardize on host endian. I don't > > remember what the reasoning was against this. > > > > > Let's suppose that we have the following two bytes in memory: > > > > > > 0x12 0x34 > > > > > > This equals to 0x1234 for big endian systems or 0x3412 for little endian > > > systems if you read data via int16_t * pointer. > > > > if sbc->endian is set to the same as the host endian, then this could > > be done with a memcopy or skipped (zero copy). > > > > I believe sbc->endian is always set to little endian the way it works > > now, meaning the array is storing data little endian regardless of the > > architecture. The patch I wrote made a copy of the memory, swapping > > bytes, if sbc->endian didn't match host endian. The way we use the > > code, this swapping only happens on big endian machines. > > Well, having no other option to verify this big endian bug, I used this MIPS > big endian QEMU image for testing: > http://people.debian.org/~aurel32/qemu/mips/ > > The current code is indeed broken on big endian systems. The attached > patch makes it work correct. Of course this part needs heavy performance > optimizations (as discussed above), but even just fixing it may be a good > idea at the moment. patch has been applied. Thanks. Regards Marcel -- 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
