maranello for staging ?

[Jim Cromie]

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 at 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 at kernel.org, I guess Id like advice and feedback 1st.

thanks