Hi Arman, >> actually we want to convert our Android support over to bt_gatt. We have the full PTS documentation and the guys are working on end-to-end test cases using the Android HAL APIs. So hopefully such a conversion will not cause any big issues. However that said, it is a conversion that we want. Sooner than later. >> > > Of course, moving the Android code over to bt_gatt makes sense, though > until then it's probably ideal not to cause any regressions in the > GAttrib code path. My idea was to start using bt_gatt in the D-Bus > daemon and get it unit tested first so that we can flush out any bugs > and then start Android discussion once we have all the confidence that > things work as intended. sounds good to me. >> I think the only problem is BtIO and that gives us a GIOChannel. However BtIO has caused us a few issues already in the past and we might need to take a step back and just take the file descriptor and free the GIOChannel after that. At the end of the day, GIOChannel has to be removed from the whole source code. So why not start with GATT. I think it is a perfect candidate for giving this a trial run. >> > > Sounds good to me. Actually, for LE connections at least, is there a > desire to move away from BtIO eventually? Why not just directly set > the socket options and open the connection in device.c? What does BtIO > do that I'm missing? For LE ATT it is not doing much. The fixed channel for ATT is super easy to handle. Either you connect() on it or you listen() + accept() and that is it. Besides the elevation of security and telling the kernel about the new MTU, it does not do anything special. That is why I am saying that for LE ATT, the file descriptor might be a lot easier than involving BtIO. However for GATT over BR/EDR, that story is not that simple. There we do not use a fixed channel and use instead a connection oriented channel. 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
