new kernel developer and preparation for upstream merge

Werner Almesberger 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
  conditions.

- 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 ?

- Werner



More information about the openmoko-kernel mailing list