Hi Arman, >> either we can convert GAttrib to use bt_att as underlying layer or we end up having to do the conversion all at once. >> >> Actually an initial starting point here could be to see how much we actually need to rely on GIOChannel for GATT. Maybe it is worth while to move the GIOChannel into GAttrib itself and just create it from the file descriptor. Once GIOChannel is an internal detail, it might be easy to switch over to struct io. All things that can be explored and need to be done eventually anyway. >> > > Yeah, actually this may not be so bad. We might be able to turn > GAttrib into a simple wrapper around a bt_att initially. I was > actually a bit hesitant to modify GAttrib at first, since I don't want > to break the Android code but I'll follow whichever route is easier in > the end. 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. > I think the GIOChannel comes from bt_io_connect and just get passed to > g_attrib_new and for the purposes of GAttrib it is already mostly an > internal detail (afaict). We could change it so that GAttrib maybe > takes in a bt_att in its constructor (or the raw fd directly). I'll > start playing with this eventually and see how it goes. 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. 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
