we have, at http://www.cs.umd.edu/projects/maranello/ Abstract In this project, we design, implement, and evaluate Maranello, a novel partial packet recovery mechanism for 802.11. In Maranello, the receiver computes checksums over blocks in corrupt packets and bundles these checksums into a negative acknowledgment sent when the sender expects to receive an acknowledgment. The sender then retransmits only those blocks for which the checksum is incorrect, and repeats this partial retransmission until it receives an acknowledgment. Successful transmissions are not burdened by additional bits and the receiver needs not infer which bits were corrupted. We implemented Maranello using OpenFWWF (open source firmware for Broadcom wireless cards) and deployed it in a small testbed. We compare Maranello to alternative recovery protocols using a trace-driven simulation and to 802.11 using a live implementation under various channel conditions. To our knowledge, Maranello is the first partial packet recovery design to be implemented in commonly-available firmware. This is cool stuff. Im probably jumping the gun a bit, but well, its cool, and I have a wrt54g router to eventually try it on. I dont however have both sides of a wifi connection, so I wont be able to actually test it. Ive taken the patches on the site, applied them to 2.6.29-rc2, and started working them a bit to make them suitable for inclusion. Naturally I have questions: I started with their patches verbatim, as this preserves their provenance, and limits my chances of screwing up and making an unmaintainable mess out of them. Does staging tree value the preservation of provenance ? Or does it want all patches in the set to be "proper" (at minimum passing checkpatch). If so, I should keep the style fixups separate, instead of folding them back in to make each patch (including the original maranello patches) pass the objective criteria. How do I balance these competing interests ? Also, I figure Im serving several different purposes (or audiences) here; - inclusion (2.6.4x ?) - maranello team (success would be them adopting this rework in progress) - OpenWRT development - serious pool of hackers and devices to test upon (10.03.1-rc4 is using 2.6.32.25 currently, I dont know future kernel plans) I have a github repo: https://github.com/jimc/linux-2.6 and have pushed the following to mx0a branch. jimc@chumly:~/projects/lx/linux-2.6$ git log --oneline 4bb61c8 maranello.h defines maranello_stats, use it. 856f571 add spaces after C keywords e1251f1 fixup C99 comments e663495 cleanfile drivers/net/wireless/b43/phy_common.h too 2c67a78 run cleanfile, fix whitespace problems added by original patches 07bc126 extract maranello common parts 1 04f010b patch -p0 < maranello_released_kernelpatches/b43.patch 59f4336 patch -p0 < maranello_released_kernelpatches/include.patch 6cc5022 patch -p0 < maranello_released_kernelpatches/mac80211.patch 1de9e8e Linux 2.6.29-rc2 I merged this branch up with 2.6.32, and found I had to do ~6 merge fixups. I tried merge --squash, in effort to catch the changes to a separate commit; but that puts the commit on the 'wrong' branch - and it ISTM that it doesnt catch just the conflict resolution diffs, but rather the sum of all the diffs in the other branch. I was hoping to do a series of merge --squashes, and adapt the branch by slowly working up the various commits of master; effectively climbing the ladder. Is this a sane, straightforward strategy ? I figured Id select merge-points with this: 'git log --oneline drivers/net/wireless/b43' Im not quite sure how to proceed with this, Ive refrained from sending to netdev@kernel.org, I guess Id like advice and feedback 1st. thanks