Proposal for further openmoko kernel development
shazalive at gmail.com
Wed Jul 29 00:01:58 CEST 2009
On Wed, Jul 29, 2009 at 2:20 AM, Lars-Peter Clausen <lars at metafoo.de> wrote:
> 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
> Or more specific how should kernel development in the openmoko tree
> 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.
I think its a neatly organized and at the same time simple to manage plan. I
am not an expert but I can volunteer to take care of the security subsystem
of the kernel. I was working on some back porting from 2.6.30 to 2.6.29-rc3
because a lot had been changed. I can track them and merge them to the tree
because I have to maintain them for a research program where integrity of
the platform needs to be measured and kernel level access controls (MAC) are
used to provide fine-grained and granular access controls at the OS level. I
am not aware of anyone maintaining the security subsystems at the moment. It
might not be a big issue but needs to be taken care off.
So when do you plan to start? Probably when it is clear that who is
interested in being involved after the execution of Plan B. Your proposed
people and associated responsibilities makes me optimistic about the
situation. I am not sure that we can have a long term plan because nobody is
manufacturing the OpenMoko devices in future. The Nanonote devices are going
to be launched with the kernel supported by X openMoko employees headed by
Steve in a new company. There are a few discussion already taking place on
the community mailing list. What should be the direction in future is not
clear at the moment but for the time being your proposal is very important
to keep things going for a while.
There were some hopes from a Brazilian University but haven't noticed any
clear signs till yet.
> - Lars
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openmoko-kernel