Hi Luiz, >>> It seems this code is not following our coding style regarding multi >>> line comments, check doc/coding-style.txt(M2: Multiple line comment) >>> the first line should be empty. >>> >> >> I didn't realize that was the comment style. I've seen both styles in >> daemon code and I think I went with this one because of that. I'd >> rather have the code be consistent (since shared/att uses this style >> elsewhere) and maybe do a style correction pass in another patch? > > Sure, I can probably fix this myself just made the comment to let you > know that we do in fact have a coding style for it. > Ah got it. >>> This might cause a problem with our own code when connecting to each >>> other if bt_att_cancel is used, apparently bt_att_cancel does not send >>> anything to the remote side which seems to enable sending a new >>> request without waiting any response for the first one. >>> >> >> I'm confused. Do you mean if bt_att is being used in the client role, >> it can send multiple requests this way? That is correct, though I >> don't see how that's related to this patch? Currently bt_att_cancel >> can be used to cancel waiting for a pending request and send the next >> one, as you said. In that regard, it doesn't actually "cancel" >> anything if the PDU has been sent over the air already. I don't know >> how big of a problem this is, since the remote end should normally >> detect the error and terminate the connection anyway. If this becomes >> a problem we can always prevent canceling a request that has already >> left the queue and is pending. Though, again, this isn't really >> related to this patch unless I'm missing something. > > Sorry for the confusion, this patch is actually fine what we really > need to fix is bt_att_cancel should not really remove the pending > request otherwise the remote may disconnect if we proceed with another > request. > Ok. I'll prepare a separate patch for that. We probably want bt_att_cancel to keep the pending request pointer but it should perhaps set the response and destroy callbacks to NULL. Same thing applies to both outgoing requests and indications. 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
