Hi Marcel, Sounds good. I had a chance to sync up with Claudio and Lizardo face-to-face today at the Bluetooth World Conference and we had a long discussion on how to do this refactor. I will go ahead and start a new (and unit tested) implementation of the ATT layer as "struct bt_att" as you suggested. I will integrate this with attrib/gatt as a first step, replacing attrib/att. I will then move on to implement a bt_gatt and bt_att_db. -Arman On Tue, Apr 8, 2014 at 6:28 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Arman, > >>> I am pretty open on how many steps we want to take at a time or what we want to do later. What I know for sure is that I >>> want to rid of GIOChannel and BtIO usage and GLib. >> >> I agree with everything you described and I think a clean GLib-free >> implementation that can be shared among Linux and Android code is the >> way to go. My only concern is that a D-Bus GATT client API is much >> needed for Chromium and I'm concerned that the big overhaul involved >> in removing BtIO and GLib is going to take too long. >> >> So my question is this: how open would you be for an initial GATT >> client API that uses the existing code in attrib/* internally? I'm >> thinking of something very similar to how android/gatt.c has been >> implemented so far. So what I have in mind is: >> >> - The bt_gatt structure you mentioned, lives in src/shared/gatt.* >> and internally uses GAttrib, etc. The code is D-Bus free and could be >> used by the GATT client code in android/gatt as well. >> - D-Bus code added to src/gatt-dbus.* to expose client objects. >> This code talks to src/shared/gatt.*. >> - src/device.* and profiles modified to use the new API with no >> explicit GIOChannel usage. > > I have no problem in doing this in parallel and take smaller or different steps. My main point is that everybody knows where we need to go in the long term. > >> What I'm suggesting is basically to make the daemon use the new API >> first and implement the new API with the existing GLib based code so >> that we have at least some implementation to work with for Chromium >> (and we isolate GLib usage to one place as far as GATT is concerned), >> and THEN implement bt_gatt, bt_att etc. the proper way. Is this >> something that you would be open to upstreaming? My primary concern is >> simply the amount of time it will take to implement a new ATT/GATT >> endpoint but if you believe that we should absolutely do it the right >> way the first time around then it's not the end of the world. > > Go ahead with it. Internal refactoring is simple. Just plan to have unit tests included that check will ensure that all changes you make are tested. > > We did this for AVDTP, AVRCP and now MCAP for our refactoring to make code shareable between Android and upstream. > > 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
