Hi Lukasz, On Fri, Mar 11, 2016 at 3:27 PM, Łukasz Rymanowski <lukasz.rymanowski@xxxxxxxxxxx> wrote: > Hi Luiz, > > On 3 December 2015 at 22:08, Łukasz Rymanowski > <lukasz.rymanowski@xxxxxxxxxxx> wrote: >> Hi Luiz, >> >> On Thu, Dec 3, 2015 at 10:27 AM, Luiz Augusto von Dentz >> <luiz.dentz@xxxxxxxxx> wrote: >>> >>> Hi Łukasz, >>> >>> On Fri, Nov 27, 2015 at 1:11 PM, Łukasz Rymanowski >>> <lukasz.rymanowski@xxxxxxxxxxx> 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. -- 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
