Hello,
This patch serie fixes a few bugs within the 6lowpan modules and prepares the
integration of the serial driver that will be submitted in a subsequent patch serie.
It should apply cleanly on the latest net-next.
Regards,
Tony Cheneau
Tony Cheneau (15):
6lowpan: lowpan_is_iid_16_bit_compressable() does not detect
compressable address correctly
6lowpan: next header is not properly set upon decompression of a UDP
header.
6lowpan: always enable link-layer acknowledgments
mac802154: turn on ACK when enabled by the upper layers
6lowpan: use short IEEE 802.15.4 addresses for broadcast destination
6lowpan: fix first fragment (FRAG1) handling
6lowpan: store fragment tag values per device instead of net stack
wide
6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer
6lowpan: add a new parameter in sysfs to turn on/off ACK request at
MAC layer
6lowpan: use the PANID provided by the device instead of a static
value
6lowpan: modify udp compression/uncompression to match the standard
6lowpan: make memory allocation atomic during 6lowpan header creation
mac802154: make mem alloc ATOMIC to prevent "scheduling while atomic"
crashes
mac802154: remove unnecessary spinlocks
mac802154: re-introduce MAC primitives required to send/receive
packets
net/ieee802154/6lowpan.c | 144 ++++++++++++++++++++++++++++++++++++---------
net/ieee802154/6lowpan.h | 14 +++--
net/mac802154/mac802154.h | 2 +
net/mac802154/mac_cmd.c | 22 +++++++-
net/mac802154/mib.c | 33 +++++++----
net/mac802154/wpan.c | 4 +-
6 files changed, 172 insertions(+), 47 deletions(-)
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
Hi,
2012/10/23 Tony Cheneau [off-list ref]:
Hello,
This patch serie fixes a few bugs within the 6lowpan modules and prepares the
integration of the serial driver that will be submitted in a subsequent patch serie.
It should apply cleanly on the latest net-next.
1. The series is quite huge what makes it difficult for the review. It
would be better to split it into one-two and submit separately (not
simultaneously).
2. Could you also please provide some notes about how have you tested
these changes (logs, plain text)? Do I need to check your changes
locally on my desk? If so I need some instructions.
3. Please DO NOT submit patches like: this patch fixes blablabla which
isn't in the kernel yet (like patch 13,15). I have no clue what you
have locally on your laptop and what you will send in some time. I'd
like to see here the working code, not a references to TBD.
4. The reference to linux-zigbee project isn't an occasion for me to
apply this code to this tree. I have no goal to merge all this fun to
mainline due to several things in linux-zigbee kernel work NOT
according to the standard (mostly it's a timing problems) and global
refactoring needed.
Alex
Regards,
Tony Cheneau
Tony Cheneau (15):
6lowpan: lowpan_is_iid_16_bit_compressable() does not detect
compressable address correctly
6lowpan: next header is not properly set upon decompression of a UDP
header.
6lowpan: always enable link-layer acknowledgments
mac802154: turn on ACK when enabled by the upper layers
6lowpan: use short IEEE 802.15.4 addresses for broadcast destination
6lowpan: fix first fragment (FRAG1) handling
6lowpan: store fragment tag values per device instead of net stack
wide
6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer
6lowpan: add a new parameter in sysfs to turn on/off ACK request at
MAC layer
6lowpan: use the PANID provided by the device instead of a static
value
6lowpan: modify udp compression/uncompression to match the standard
6lowpan: make memory allocation atomic during 6lowpan header creation
mac802154: make mem alloc ATOMIC to prevent "scheduling while atomic"
crashes
mac802154: remove unnecessary spinlocks
mac802154: re-introduce MAC primitives required to send/receive
packets
net/ieee802154/6lowpan.c | 144 ++++++++++++++++++++++++++++++++++++---------
net/ieee802154/6lowpan.h | 14 +++--
net/mac802154/mac802154.h | 2 +
net/mac802154/mac_cmd.c | 22 +++++++-
net/mac802154/mib.c | 33 +++++++----
net/mac802154/wpan.c | 4 +-
6 files changed, 172 insertions(+), 47 deletions(-)
--
1.7.8.6
Hello Alexander,
Thank you for your comments. See my answer inline.
Le 25.10.2012 06:52, Alexander Smirnov a écrit :
Hi,
[...]
1. The series is quite huge what makes it difficult for the review. It
would be better to split it into one-two and submit separately (not
simultaneously).
OK. Will do.
2. Could you also please provide some notes about how have you tested
these changes (logs, plain text)? Do I need to check your changes
locally on my desk? If so I need some instructions.
I'm not sure what you are asking here. There was some more debugging printk, that I removed because they were too verbose. Mostly, I test my patch with few userspace program, like ping6, iperf (both for TCP and UDP) and ssh. I also wrote a TCP and a UDP echo server, so as to test fragmentation in more details. For most functional patches, I usually confirm through wireshark that the packets indeed look the way they should (this, I've done it for patch 11 for example). But I don't have any automated scripts to check for regression. I can provide you the script I use to configure nodes if needed (but it pretty straighward and should look like your own scripts).
I'm not sure that really answers your question.
3. Please DO NOT submit patches like: this patch fixes blablabla which
isn't in the kernel yet (like patch 13,15). I have no clue what you
have locally on your laptop and what you will send in some time. I'd
like to see here the working code, not a references to TBD.
I'm OK with removing patch 13 (I'll introduce it alongside the serial driver later on). I'm not so OK with removing patch 15, or at least, it would require some more testing in other parts of the code. Basically, the TBD are placeholder for when the Association Request/Response will be reimplemented. I introduced it because otherwise, .assoc_req and .assoc_resp entries of mac802154_mlme_wpan would go uninitialized and would cause kernel crash when called. I could have modified the calling code to deal with that, but I thought these primitives were meant to be re-implemented soon anyway.
4. The reference to linux-zigbee project isn't an occasion for me to
apply this code to this tree. I have no goal to merge all this fun to
mainline due to several things in linux-zigbee kernel work NOT
according to the standard (mostly it's a timing problems) and global
refactoring needed.
I don't understand what you are talking about here. I would guess that you are talking about patch 15. If so, my answer is the following, while I understand your effort to refactor linux-zigbee code and fix things along the way, some code went through net-next that cause crashes. My pragmatic approach is to try to fix it before more people use it, even through it might not always be the most elegant way to do it.
Regards,
Tony