Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1448622711-17562-1-git-send-email-lukasz.rymanowski@codecoup.pl> <1448622711-17562-2-git-send-email-lukasz.rymanowski@codecoup.pl> Date: Fri, 11 Mar 2016 16:30:32 +0200 Message-ID: Subject: Re: [PATCH v2 01/11] unit/test-gatt: Fix long write testcases From: Luiz Augusto von Dentz To: =?UTF-8?Q?=C5=81ukasz_Rymanowski?= Cc: "linux-bluetooth@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Lukasz, On Fri, Mar 11, 2016 at 3:27 PM, Łukasz Rymanowski wrote: > Hi Luiz, > > On 3 December 2015 at 22:08, Łukasz Rymanowski > wrote: >> Hi Luiz, >> >> On Thu, Dec 3, 2015 at 10:27 AM, Luiz Augusto von Dentz >> wrote: >>> >>> Hi Łukasz, >>> >>> On Fri, Nov 27, 2015 at 1:11 PM, Łukasz Rymanowski >>> wrote: >>> > Idea of long write is that each part of data is continuation >>> > of previous one. There shall be not gaps in the offsets between. >>> > >>> > If there are gaps in offset then we have reliable write rather than >>> > long write >>> >>> The patch looks fine what I did not understand is what different it >>> makes if it is a reliable write or a long write, to me all long writes >>> are in fact reliable write since it does use prepare + execute, the >>> fact that only one handle is written doesn't change anything. >>> >> >> These testes are for Long write and there is a difference between Long Write and >> Reliable Write even those two use prepare/execute writes. This can be >> found in the >> BT Spec Chapter 3 Part G, 4.9.4 and 4.9.5 >> >> Basically those procedure belongs to GATT and our gatt server should >> understand that. >> >> If we are going to not expose prepare/execute wirtes to application, >> then this is GATT server which should >> recognize procedure and prepare data to be written to application. >> i.e. for long write do aggregation of all >> prepare writes, we can not just write part of data as this would cause >> some unexpected behavior. >> >> We also need this change, because following patches will start to test >> for characteristic extended properties >> descriptor and do not allow reliable write on characteristics which >> does not have property for this. >> Note that for Long Write we don't need this descriptor property, so >> these test cases would fail then. >> >> Also, note that there is Long Write procedure for descriptors but >> there is no Reliable Write procedure for >> descriptors, so we definitely cannot treat long and prepare as the same one. >> >> > Was my explanation clear enough? > > Just getting back to this work and we have some outstanding patches in > this patchset > which should be OK to apply. I guess my point was not really against this patch but more on the detection of reliable write vs long write.