new kernel developer and preparation for upstream merge
werner at openmoko.org
Fri Sep 19 14:44:09 CEST 2008
Balaji Rao is joining Openmoko as a new kernel developer who will help
with the upstream merge. Welcome, Balaji !
Wolfgang has asked me to write down what tasks need to be done in
order to tackle this, and where Balaji can help. Here's the plan
(slightly edited from the draft I sent in private mail before):
I see basically the following phases for pushing things upstream:
- review and clean them up to the point that we're happy with them
- separate the parts that aren't suitable yet for upstream, such
as WLAN or our "private" USB IDs
- break the rest into manageable pieces
- submit them for review
- handle the rejects, possibly moving things into the "later" pile
- resubmit for review, if needed
- submit for inclusion
- handle any fallout, e.g., if problems are discovered after a
patch has been accepted
Not everything needs all this. E.g., a simple fix for an upstream
bug can skip right to final submission, and there are some changes
that can be handled apart from the rest. Larger changes also need
synchronizing with upstream's merge window.
The cleanup would also be an excellent opportunity to visit all our
code and to form a battle plan for the later stages. I currently see
the following tasks there:
- make sure we use consistent naming, e.g., Openmoko-specific things
shouldn't be named s3c_something and vice versa. There's a number
of bad examples in arch/arm/mach-s3c2440/mach-gta02.c, and I'm sure
there are plenty more in our tree.
- some of our code has grown a bit complex and could benefit from
refactoring. In particular, large functions should be broken down
into smaller pieces.
- check that the logic of the code makes sense. We will get asked to
explain how and why something works, so we better have our homework
in good shape. This is also an opportunity to look for race
- make sure the code still compiles if individual config options are
disables or enable. I'd suggest to try all our options, none of our
options, walk through the list of out options and enable/disable
them one at a time, and finally try random combinations. This
should be automated, of course.
- we also have some contamination of platform-specific code in
platform-independent drivers. Sometimes, this is covered up by
platform callbacks, but that's cheating :) Fixing those problems is
more demanding than the other items I've listed.
- mach-gta02.c wants breaking down into smaller pieces, probably into
a new subdirectory. This would be an apparently unprecedented
exercise, so we have to ask on linux-arm whether they'd welcome the
idea, and what naming conventions to use.
Then we'll have to turn our chain of git commits into sequential topic
patches. This is the hard part, particularly since we have to expect
that there will be a lot of small issues with the first patches we
submit, and we'll have to keep these topic patches alive for a while.
This is the task everybody is scared of, because it's such a lot of
code. None of the kernel developers I've talked to about this has had
any more encouring advice than to wish us luck :-)
My idea is to semi-automate this task: define which files should go
into which topic patch, and then a program can find out what sort of
conflicts this would cause. Then these conflicts can be removed by
specifying more details and/or reverting patches, separating them,
and checking them in again.
That way, we can put all the cleanup and fixes into git as usual, and
just generate a new set of topic patches in the end. No need to branch
and maintain parallel trees with dozen or even hundreds of shared
commits for months.
I've started to work a bit on that program that can generate topic
patches directly from our repository, but I realized later that I
tried to be too clever about how this tracked changes and that my
algorithm wouldn't work. (I tried to make it track the history of
every single line, but there are too many ambiguities to handle.)
So I'll have to do this again. It's been mainly a pencil and paper
exercise so far anyway.
My suggestion would be that you start with the internal cleanup. When
I'm done with WLAN, I'll write my new and improved patch maker, and
then we can synchronize and prepare for the big push.
The cleanup tasks I've outlined above can be done in pretty much any
order and they can of course also be combined in any way you like.
Does that sound good ?
More information about the openmoko-kernel