Proposal for further openmoko kernel development

[Lars-Peter Clausen]

Hi

With the upcoming 2.6.31 kernel release basic support for the freerunner 
as finally reached upstream. (Well, ok you need a few patches to make it 
boot, but pretty much all the basics are there).
So this raises the question what does this mean for us, those actively 
contribute to the om kernel. What does this mean for the community and 
distributions?
Or more specific how should kernel development in the openmoko tree 
continue?

Currently we have andy-tracking which is based on 2.6.29-rc3. And in my 
opinion andy-tracking is in a very bad shape, there is lot of obsolete 
stuff in there, like the support for the gta03 and some leftovers from 
code refactoring. Furthermore it has been merged several times with all 
kinds of different trees, which results in a rather interesting history. 
Patches which were applied to the tree usually touch several subsystems 
at once. So if you want to extract a patch to get a single subsystem 
running (for example for upstream submission) you have to crawl through 
several commits and pick the pieces you need. Last but not least the 
tree contains support for two different (although quite similar) 
machines, namely the gta01 and gta02. All this sums up to a huge pile of 
unmaintainable patches making rebasing almost impossible.

Thus I propose a different development model for future kernel development:
The basic idea behind this approach is to get rid of the centralized 
development model and go over to a more modular one. Instead of having 
one big monolithic tree containing everything, we'll have several 
subtrees for each driver. On top of that would be two machine trees and 
maybe one for s3c specific patches. The machine specific trees would  
then regularly merge those driver trees they need.
On top of of the machine trees there would be a combined tree where both 
machine trees get merged. The purpose of this tree is to provide a 
single point which provides everything needed for openmoko based devices 
from where distributions can pull to build their kernels.

Ideally all trees would be initially based on the upstream kernel. 
Driver trees would only have driver specific code added to them. As you 
can see, the goal of those trees it not to provide a full functional or 
bootable kernel but a trackable patchset.
During development a developer would probably work on the machine tree 
to create and test his patches and rebase those when ready onto the 
driver tree. And only the commits to the driver tree would be published.
I also suggest to rebase our trees every major upstream release onto the 
new upstream, to keep up with the latest changes in upstream and again 
to keep the patchset maintainable.
On the other hand I'm not an git expert and there might be other better 
approaches, so feel free to send suggestions.

The benefit of this approach compared to the current model is that we 
have a clean set of patches for each subsystem which makes rebasing and 
possible upstream submission a lot easier. Furthermore this clearly 
defines who is responsible for what. With the current model we have 3 or 
4 people who have access to git, but there hasn't been any agreement 
about what should be done by whom. Which as a result has led to some 
confusion in the past, with none committing potential patches.

To sum this all up, a small diagram ;) (best viewed with a monospace font)

                  combined openmoko tree
                       /           \
platform level:    gta01 tree    gta02 tree ---- s3c patches
                     /       \   /    \     \
driver level: ...  pcf50606   jbt6k   glamo  bq27000 ...

What would have to be done to put this plan into action is to set up 
trees and provide access to those who need it. And to clarify who wants 
to take care of what.
Nelson would probably regain his position as the "gate keeper", who as a 
maintainer decides what goes into the machine trees.
I guess Paul wants to work on battery and regulator stuff, Werner on the 
ar6000. I would like to take care of the jbt6k and together with Thomas 
of the glamo.

I do have patches against 2.6.31 for full gta02 support which could be 
used to initialize the trees to get them functional.

Oh, and one downside of the transition could be that we loose patches. 
So if you know of any important patches which not have been merged 
upstream, but are for an upstream driver, please try to make sure that 
they either get merged upstream or find their way into the machine trees.

Please tell me what you think of this proposal.

- Lars