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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

--
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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux