Re: [RFCv0 0/5] extended window size and extended control field support

[Mat Martineau <mathewm@codeaurora.org>]

On Tue, 30 Aug 2011, Marcel Holtmann wrote:

> Hi Mat,
>
>>> First draft patches applied to my previous EFS patches. Please comment.
>>>
>>> Adds support for extended window size option (EWS) and extended control
>>> field. Code partly based on Atheros patches sent a year ago and Qualcomm
>>> code git://codeaurora.org/kernel/msm.git.
>>>
>>> To decode EWS option and extended control field please apply patch to hcidump
>>> which I sent to linux-bluetooth.
>>>
>>> Andrei Emeltchenko (5):
>>>  Bluetooth: extended window size option support
>>>  Bluetooth: l2cap extended control field support
>>>  Bluetooth: EWS: support extended seq numbers
>>>  Bluetooth: remove magic numbers in l2cap
>>>  Bluetooth: prevent unneeded fragmentation in l2cap
>>>
>>> include/net/bluetooth/l2cap.h |  304 ++++++++++++++++++++++----
>>> net/bluetooth/l2cap_core.c    |  481 +++++++++++++++++++++++++----------------
>>> net/bluetooth/l2cap_sock.c    |   11 +-
>>> 3 files changed, 562 insertions(+), 234 deletions(-)
>>>
>>> --
>>> 1.7.4.1
>>
>> Extended window size is next on my list to upstream.  As you probably
>> noticed, the git://codeaurora.org/kernel/msm.git code has a slightly
>> different approach to handling the two control field types.  The
>> fields are handled in a struct that's part of the bt_cb control block,
>> and only read/written in wire format when the frame is first received
>> or about to be sent.  Are there any issues with this method (other
>> than the fact that I haven't upstreamed it yet)?  Some of the
>> subsequent L2CAP state machine changes depend on this.
>
> in general using bt_cb is fine, but it depends a little bit on the
> details. The space of the skb cb is limited. So we need to be cautious
> here.

Yes, I've been keeping that limited space in mind.  Some of the data 
already in bt_cb was control field data, so I removed the redundant 
entries.

> We are also currently making bt_cb global for all protocols. Maybe one
> way is to have l2cap_cb for this. We need to see what makes more sense
> and what is more efficient.
>
>> Please let me know if there are specific features from the
>> git://codeaurora.org/kernel/msm.git code base that you would like to
>> prioritize for upstreaming - there's a lot to do to bring in those
>> L2CAP and AMP changes, and I'll have more time to devote to it in
>> mid-September.  I think we can gain a lot by reviewing each other's
>> patches and coordinating our efforts.
>
> Maybe just for reference, you should post a set of patches to the
> mailing list so they are archived and seen by others. Digging into a
> generic msm.git tree is not really efficient.

I'll take a look at that - I'd have to split up the commits in that 
git repository in order for them to be suitable for the mailing list.


--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum