Froyo and kernel version

[hedwin]

Hi,

Which kernel version do I need to use for Froyo?
I tried the same version as used for Eclair (2.6.32) but that does
work for Froyo.

Hedwin

[Akash Choudhari]

Eclair was on 2.6.29 and Froyo is on 2.6.35

Are you using Google GIT to get the kernel?

-Akash

> --
> unsubscribe: android-kerne...@googlegroups.com
> website: http://groups.google.com/group/android-kernel

--
Sent from my mobile device

[Mike Lockwood]

Actually Froyo is 2.6.32. 2.6.35 is being used for post-Froyo development.

Mike

--
Mike Lockwood
Google android team

[hedwin]

Ok, thnx. That's what I assumed looking into the git repos.

@Akash. Not using the google git kernel directly but more as a
reference point. Using linux omap from git.kernel.org

[markgross]

I keep getting asked about kernel versions and android releases at
work too.

I keep telling people that the only kernel requirements any version of
Android has are that its a 2.6 kernel (for bionic) and it has a small
set of patches (binder, logger, wakelocks, ashmem, and perhaps a few
others that the user stack assumes or are needed for security
enhancements) But, every couple of weeks the question comes in again.

Your hardware needs the newest kernel you can get booting as early in
the effort as you can have it. But, that's not an android
requierment.

I would like it if the google android team could help clear up what I
think are the erroneous assumptions regarding kernel versions needed
for different versions of android.

--mgross

[markgross]

I am booting Froyo (and Eclair) on a 2.6.31 and 2.6.34 kernels today,
I would bet money you could boot them on a 2.6.29 kernel as well.

You just need the critical kenrel patches for it to work. i.e.
binder, asmem, wakelocks, logger, and one or two more, you can easily
rebase out of the refrence kernel trees google puts up.

--mgross

On Aug 4, 3:17 pm, hedwin <hedwin.kon...@gmail.com> wrote:

[hedwin]

What I understood is that bionic needs to be in sync with the kernel.
But getting bionic in sync is a lengthy process.
It feels easier to use git to cherrypick the google specific changes
to a newer kernel version. This is how I do it now.
But it would still be helpfull if the google guys/girls just indicate
which kernel version to use for which android version.
Just a single line on a wiki would make a big difference.
Now the question to figure out which needs to be used for what is a
never ending question on the goolge forums.

[scorproy]

A noobish question kernel gurus:
1. How do I cherry pick the Froyo changes other than the kernel using
repo, for if I use the standard repo command, it syncs up everything
in the latest release.
2. In repo, how do I list down all the projects in a manifest file,
the output of which I can use in rep forall command.
These 2 may not be related to the kernel, as you all are doing the
repo cherrypicking stuff, any info would be of great help.
Thanks in advance for our help
Arindam

On Aug 6, 11:49 pm, hedwin <hedwin.kon...@gmail.com> wrote:
> What I understood is that bionic needs to be in sync with the kernel.
> But getting bionic in sync is a lengthy process.
> It feels easier to use git to cherrypick the google specific changes
> to a newer kernel version. This is how I do it now.
> But it would still be helpfull if the google guys/girls just indicate
> which kernel version to use for which android version.
> Just a single line on a wiki would make a big difference.
> Now the question to figure out which needs to be used for what is a
> never ending question on the goolge forums.
>
>
>

> On Fri, Aug 6, 2010 at 5:03 PM, markgross <mark.gr...@intel.com> wrote:
> > I am bootingFroyo(and Eclair) on a 2.6.31 and 2.6.34 kernels today,

[Vikram]

hi Mark

Why do you say there is no relationship between userspace and the
kernel version?

Did you check:
Kernel:
include/linux/....

and

Android 2.2:
bionic/libc/kernel/common/linux/.....

There are same header files shared between kernel and the filesystem.
thus introducing a dependency between filesystem and the kernel
version.


Some script is run on kernel headers to generate the filesystem
headers and i think Android team must be doing it once every pastry
release.

See example header:
http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=libc/kernel/common/linux/types.h;h=b118db0f392272146a8b88ad169aeb7729139a14;hb=master#l1
1 /
****************************************************************************
2
****************************************************************************
3 ***
4 *** This header was automatically generated from a Linux
kernel header
5 *** of the same name, to make information necessary for
userspace to
6 *** call into the kernel available to libc. It contains only
constants,
7 *** structures, and macros generated from the original header,
and thus,
8 *** contains no copyrightable information.
9 ***
10
****************************************************************************
11
****************************************************************************/

[markgross]

Glibc has a dependency on the 2.6 kenrel tree too, but that doesn't
mean there is a dependency between on 2.6 kernel and another for
propper user mode support.

Yes I have seen those files. They define the sys call ABI that bionic
uses. There is nothing magic or tightly coupled to the specific
kernel version other than you need a newer kernel than 2.4 to satisfy
the assupmtions therein.

All thats important is the kernel expose the kernel ABI assumed by the
user mode. So far that is only:
2.6 erra sys_calls for the android libc (bionic)
binder
wake lock
ashmem
early (consol) suspend
logger

(i think thats all, asside from stuff thats already in the upstream
kernel tree like frame buffer, audio, network, input, and a few other
things you need to be sure to have enabled in your kernel config.)


--mark

On Sep 22, 10:38 am, Vikram <vikrampand...@gmail.com> wrote:
> hi Mark
>
> Why do you say there is no relationship between userspace and the
> kernel version?
>
> Did you check:
> Kernel:
> include/linux/....
>
> and
>
> Android 2.2:
> bionic/libc/kernel/common/linux/.....
>
> There are same header files shared between kernel and the filesystem.
> thus introducing a dependency between filesystem and the kernel
> version.
>
> Some script is run on kernel headers to generate the filesystem
> headers and i think Android team must be doing it once every pastry
> release.
>

> See example header:http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=libc/ke...
>    1 /
> ***************************************************************************­*
>    2
> ***************************************************************************­*

>    3  ***
>    4  ***   This header was automatically generated from a Linux
> kernel header
>    5  ***   of the same name, to make information necessary for
> userspace to
>    6  ***   call into the kernel available to libc.  It contains only
> constants,
>    7  ***   structures, and macros generated from the original header,
> and thus,
>    8  ***   contains no copyrightable information.
>    9  ***
>   10

> ***************************************************************************­*
>   11
> ***************************************************************************­*/

[Dianne Hackborn]

We develop each version of Android against a specific version of the kernel, and make little to no attempt to see if it works on earlier versions of the kernel.  It seems like more often than not if we try to run a newer version of the platform with the kernel from a previous version that there is one or another kind of problem, due to subtle differences between them in /proc or various other things besides sys calls.

If you are going to use an older version of the kernel than what a particular version of the platform targets, you just need to expect that there may be things here and there you need to fix.

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[hedwin]

Some time back I was looking at froyo and what I could find on
android.git.kernel.org suggested it might be using kernel version .35
while others were using kernel version .32
So how to know what kernel version to use for which android version?

[Teck Choon Giam]

Hi,

On Sat, Sep 25, 2010 at 3:24 AM, hedwin <hedwin...@gmail.com> wrote:
> Some time back I was looking at froyo and what I could find on
> android.git.kernel.org suggested it might be using kernel version .35
> while others were using kernel version .32
> So how to know what kernel version to use for which android version?

Maybe you can see under "Update history" for the below URL:
http://en.wikipedia.org/wiki/Android_%28operating_system%29

Hope this helps!

Thanks.

Kindest regards,
Giam Teck Choon

[hedwin]

Yes, thanks for the tip.

[Dianne Hackborn]

Here's a story illustrating why I would recommend sticking with the same version of the kernel that a particular version of Android was developed against (at least initially).

Froyo was developed against 2.6.32.  We are currently developing against 2.6.35 post-Froyo.

I and many others have just gone through literally *weeks* of effort trying to fix some problems in the development code, causing everything from individual apps ANRing with no clear reason, through the entire system just stopping for 30s or more, to the entire kernel crashing.

It turns out that a lot of this (though not all) is due to some issues in the 2.6.35 kernel with what happens when running threads switch between cgroups.  (This is something that Android does a lot, which probably nobody else using Linux does.)

So in theory, yes you can say that user space is independent from the kernel, and you won't have a problem switching to a different kernel.  In practice, however, there are all kinds of subtle interactions that can come up due to bugs in user space or the kernel or not even bugs but just differences in behavior that when put together cause serious problems.

When you start out, you really want to change as little as possible.  The faster you can get to a stable running system, the easier a time you will have in the future when things fall apart (as they inevitably will).  If you can know that at point A things were fine, that greatly narrows down what you need to dig into to figure out what has gone wrong at point B.

On Wed, Sep 22, 2010 at 6:59 PM, markgross <mark....@intel.com> wrote:

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

[Arindam Roy]

Also Diane, I think it wouldn't be a good idea, not to use the same kernel as the android git, as that undoes the effort that your team has spent, and leads to duplication.

Another point is, if one is using the same kernel, and reports any issue to this list, then all the others can easily help. Otherwise these subtle differences as you mentioned may inhibit the reproduction of the same  issue for different developers.

Thanks,

Arindam

[Rehmet]

Thanks Dianne,

That is really excellent insider's tip we need to know about.

I will now be using v.2.6.32 for FPGA's linux distribution

On Oct 4, 12:07 pm, Arindam Roy <rarin...@gmail.com> wrote:
> Also Diane, I think it wouldn't be a good idea, not to use the same kernel
> as the android git, as that undoes the effort that your team has spent, and
> leads to duplication.
> Another point is, if one is using the same kernel, and reports any issue to
> this list, then all the others can easily help. Otherwise these subtle
> differences as you mentioned may inhibit the reproduction of the same  issue
> for different developers.
> Thanks,
> Arindam
>

> On Mon, Oct 4, 2010 at 10:27 AM, Dianne Hackborn <hack...@android.com>wrote:
>
> > Here's a story illustrating why I would recommend sticking with the same
> > version of the kernel that a particular version of Android was developed
> > against (at least initially).
>
> > Froyo was developed against 2.6.32.  We are currently developing against
> > 2.6.35 post-Froyo.
>
> > I and many others have just gone through literally *weeks* of effort trying
> > to fix some problems in the development code, causing everything from
> > individual apps ANRing with no clear reason, through the entire system just
> > stopping for 30s or more, to the entire kernel crashing.
>
> > It turns out that a lot of this (though not all) is due to some issues in
> > the 2.6.35 kernel with what happens when running threads switch between
> > cgroups.  (This is something that Android does a lot, which probably nobody
> > else using Linux does.)
>
> > So in theory, yes you can say that user space is independent from the
> > kernel, and you won't have a problem switching to a different kernel.  In
> > practice, however, there are all kinds of subtle interactions that can come
> > up due to bugs in user space or the kernel or not even bugs but just
> > differences in behavior that when put together cause serious problems.
>
> > When you start out, you really want to change as little as possible.  The
> > faster you can get to a stable running system, the easier a time you will
> > have in the future when things fall apart (as they inevitably will).  If you
> > can know that at point A things were fine, that greatly narrows down what
> > you need to dig into to figure out what has gone wrong at point B.
>

> >> unsubscribe: android-kerne...@googlegroups.com<android-kernel%2Bunsu...@googlegroups.com>

> >> website:http://groups.google.com/group/android-kernel
>
> > --
> > Dianne Hackborn
> > Android framework engineer

> > hack...@android.com

>
> > Note: please don't send private questions to me, as I don't have time to
> > provide private support, and so won't reply to such e-mails.  All such
> > questions should be posted on public forums, where I and others can see and
> > answer them.
>
> >  --

> > unsubscribe: android-kerne...@googlegroups.com<android-kernel%2Bunsu...@googlegroups.com>
> > website:http://groups.google.com/group/android-kernel
>
>

[steve paesani]

I like Mark's approach and here's why:
Device vendors, by Android Licensing, must release their source code.
They do not however have to provide updates for any particular device.
When a new Android comes out a device vendor may simply decide to not port it to an 'old device' yet rather
port it to some new and improved device. Though I respect Diane's advice I can not help but notice the cohesion between it and many a device vendor's intent to sell more phones based on a new android release.
Mark's view and approach however lends to those who  might port a new android to an older device whose source and drivers are publicly available. Thus something like an Ice Cream Sandwich can be 'back ported' to an 'abandoned' device.
Something those concerned about society as a whole, and not the 'succecss' of one of it's sub cultures, finds rather attractive.
Thanks Mark!