Freerunner android wifi

Andy Green andy at
Wed Dec 31 18:03:20 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

| I agree that it would be best to have a single kernel tree for all
| Freerunner derived distributions, and Marcelo and I will help work
| towards that with Openmoko with respect to Android.


| What we would like to see though, is a greater effort in the following
| areas:
| -Determine a tagging structure so that testing can take place at
| well-defined points in development. There has been much change in
| certain branches (particularly andy-tracking), causing some regressions
| in particular areas (ie: charging).

Right now we're living out of a tracking branch, and that's doing its
job "tracking" upstream changes.  When we fork this into the new stable,
we won't be rebasing all the time as we are now (and introducing some
incomplete code like recent pm tree changes).  So we shouldn't be
surprised it is up and down in *-tracking mode.

We can tag things, but what do you actually have in mind when you say
"testing can take place at well-defined points in development"?  Just
tagging stuff isn't really going to deliver what it sounds like you are
thinking about there.

What exactly is wrong with charging on current andy-tracking?  AFAIK
it's really good since Balaji's changes to pcf50633 and more recently
charger restart on full stuff.  Please test current HEAD and send Trac
reports or patches.

| -Determine a method of testing of new kernels allowing to find any
| regressions in functionality

Wendy in Openmoko does run and report regression tests independently
already, so far nobody has packaged 2.6.28 stuff for her to try AFAIK
due to "recent upheavals".  When that is done, I expect this will be a
good way to find trouble.

Of course, you are welcome to feed this list and Trac with stuff you
find, or patches.

| -Documentation of the status of the kernel, and the stability of the
| various subsystems

Really this is Trac.  I'll have a think if it makes sense to maintain a
wiki page or something with overview.

| In addition, I would like to explore how we might start to push some of
| the Openmoko code back to the kernel mainline via the kernel staging
| branch. The issue lies in being able to cross-pollinate the changes from
| Android into the kernel as well as those for the Openmoko kernel.

It it really down to us to push the Android changes?  I would have
thought Google would have been doing that.  For getting the rest of our
stuff upstream we have started it, but it is going to be a slow process.

| What's driving this is the demand from our customers to have staged
| kernels with well defined and tested subsystems.

It will be great if Koolu are going to help with testing "subsystems"
and increasing our quality.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list