This section documents the development process for 802.11 and the trees used.
- Developer process
- Patch review process
- Maintainer chain
- The Linux kernel maintainer - Linus Torvalds
- The linux-next integration testing tree maintainer - Stephen Rothwell
- The Networking subsystem maintainer - David S. Miller
- The 802.11 subsystem maintainer - John W. Linville
- The mac80211 and cfg80211 maintainer - Johannes Berg
- The 802.11 driver maintainers
- Other documentation/presentations
Patch review process
Patches for the 802.11 subsystem must be sent to John and posted to the linux-wireles mailing list. For details of the patch format review the patch submission guide for 802.11 and our git guide. Once posted the patches will got through a review process by the community. Anyone can post comments regarding your patch, you should try to be responsive and address any questions asked.
If developers raise issues with your patch you are expected to follow up with another iteration of your patch or series of patches. In your new iteration of patches you should specify that these patches are part of a new iteration. You can do this by specifying the iteration number on the subject. For example, for a second iteration you would use:
You can specify this with git by using an argument to git format-patch:
The review process completes once no one has posted concerns, questions or comments, or explicitly has ACKed the patch. John will usually merge the patch the week the review process completes.
802.11 development follows the usual Linux kernel development style and has one maintainer assigned to the entire subsystem. Apart from that we also have specific component maintainers for each major component part of the 802.11 subsystem and we also have specific driver maintainers.
The diagram below illustrates the chain of how patches get into Linux for 802.11:
We detail below the maintainers an 802.11 patch usually goes through for inclusion into Linux.
The Linux kernel maintainer - Linus Torvalds
Linus maintains the Linux kernel as a whole. He receives patches from every major subsystem, a couple relevant examples are patches from David Miller for the Networking subsystem and patches from Greg Kroah-Hartman for the USB subsystem.
Linus makes stable kernel.org releases based off of this tree:
The linux-next integration testing tree maintainer - Stephen Rothwell
Stephen maintains a tree to help with the testing of patches which are to be eventually sent to Linus Torvalds for the next kernel release. If kernel.org indicates the latest stable kernel is 2.6.33 it means that the patches in Stephen's linux-next.git are patches which will likely end up being sent to Linus Torvalds for inclusion into the 2.6.34 kernel release.
linux-next.git - subsystem maintainers send their queued up patches to Stephen for integration and testing
The Networking subsystem maintainer - David S. Miller
Amongst other things David maintainers the network subsystem for the Linux kernel. All networking subsystem maintainers send patch updates to David, this includes the 802.11 maintainer and the Bluetooth maintainer.
Relevant trees to 802.11 that David maintains:
The 802.11 subsystem maintainer - John W. Linville
John W. Linville is the Linux kernel 802.11 subsystem maintainer. As a maintainer he reads all patches posted to the linux-wireless mailing list, and once ready merges them into the development and stable trees.
John uses three trees for overall 802.11 maintenance:
The differences between these are explained below.
The wireless-testing.git tree is wireless git tree that contains the latest and greatest wireless core changes, mac80211 changes and wireless drivers. As developers post patches to the linux-wireless mailing list John eventually merges the patches after a review process the patches get merged into this tree. This is the first tree where all development patches get merged into and is updated about twice a week.
John will update his tree to get any new updates from Linus by pulling the linux-2.6.git tree. Linus' tree will have all updates to the stable kernel including John's last batch of updates through the wireless-2.6.git tree. When John pulls this tree he will deal with any merge conflicts.
Developers should work off of this git tree for all 802.11 development. Developers can simply pull the tree for new updates if no changes have been made committed locally. If you do have changes committed locally you can rebase your tree on top of John's by doing the following instead of pulling:
git fetch git rebase origin/master
Detailed changes for this tree:
The wireless-next-2.6.git tree is used by John to push patches to the respective net-next-2.6.git tree maintained by David. For example if the latest stable kernel release is 2.6.33 then Networking patches for the next kernel release are queued in the David Miller's net-next-2.6.git tree, and in this case it would be for the 2.6.34 kernel release. John pushes patches to David by referring to his own wireless-next-2.6.git tree. Prior to sending new changes to David John pull's David's tree into his own tree and addresses any merge conflicts. David's tree would have had the last batch updates John sent to David plus any new networking changes David has picked up from anyone else. David would merge the new 802.11 wireless-next-2.6.git tree changes and at that point the net-next-2.6.git tree becomes in synch with John's queue of 802.11 changes for the next kernel release. David Miller will eventually send his own set of queued up patches to Stephen for the linux-next.git tree.
The wireless-2.6.git tree is used to pushing wireless patches to the current -rc release of the Linux kernel. For example If the latest stable kernel release is 2.6.33, John will use his wireless-2.6.git tree to send updates to 2.6.34-rc releases.
The mac80211 and cfg80211 maintainer - Johannes Berg
Johannes maintains the cfg80211 and the mac80211 components of the 802.11 subsystem. This means patches for either mac80211 or cfg80211 should be addressed to him and that he will pro actively review them.
The 802.11 driver maintainers
Each driver has its own set of maintainers and patches for each driver should be sent to them as well. These driver developers will pro actively review patches posted. See the 802.11 driver maintainers page for details.