Return-Path: MIME-Version: 1.0 Sender: armansito@google.com In-Reply-To: References: <1409295566-13583-1-git-send-email-chao.jie.gu@intel.com> <3D02B219753AD44CBDDDE484323B1774112F697D@SHSMSX104.ccr.corp.intel.com> <3D02B219753AD44CBDDDE484323B1774112F6F57@SHSMSX104.ccr.corp.intel.com> <7926AF24-265F-454D-A502-C3554072752E@holtmann.org> Date: Fri, 5 Sep 2014 07:46:02 -0700 Message-ID: Subject: Re: [PATCH] gatt api V2 From: Arman Uguray To: Marcel Holtmann Cc: "Gu, Chao Jie" , Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 List-ID: Hi Marcel, > 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 case= s 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. > 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 ta= ke a step back and just take the file descriptor and free the GIOChannel af= ter that. At the end of the day, GIOChannel has to be removed from the whol= e source code. So why not start with GATT. I think it is a perfect candidat= e 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? Cheers, Arman