Hi Marcel, > 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. 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. Cheers, Arman -- 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
