Linux kernel modifications for Android
noamtm
the changes and configuration done to the vanilla kernel in order to
support Android.
It *must* be documented somewhere: if I am to get the source from
kernel.org, what set of patches do I have to apply, and what config do
I use, to make it compatible with Android?
Thanks, Noam.
Tim Bird
I have heard rumors of people saying they would make separate patches
available, but after looking myself I couldn't find anything. As
far as I know, the only way to get a kernel with the required Android
features is to use one from an existing Android-based git repository.
I spent some time looking at the Mistral port of Android to the
OMAP3EVM, and came up with a list of kernel features (but alas, not
a set of independent patches).
Some raw unfinished notes are at:
http://elinux.org/Android_Kernel_Features
If anyone wants to add to these, feel free.
Note that the config options used by Android are in
the file Documentation/android.txt in the kernel source
tree (from an Android repository).
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
Chih-Wei
repository.
Why can't you find it?
A simple git merge-base can tell you the forked point
of Android branch. For example, to find the commit
from which android-2.6.29 forked:
git merge-base v2.6.29 korg/android-2.6.29
On 1月6日, 上午4時56分, Tim Bird <tim.b...@am.sony.com> wrote:
Tim Bird
> All the patches (changes) are available in Android kernel git
> repository.
> Why can't you find it?
from git commits is not as easy to work with as a set of
patches that are maintained along feature boundaries.
Most Linux distributions, and several Linux projects, manage
their patches using a combination of git and quilt (or stgit, or
some such). This preserves the patch boundaries and makes it
much easier, IMHO, to move features between kernel versions
and among kernels with different sets of board support and
drivers.
I'm mildly surprised that Google doesn't manage their patches
against mainline in this format, rather than raw git format.
In my experience, it's a good format for managing patches which for
one reason or another don't end up getting mainlined.
But then again, I'm not a git expert, and maybe everything
I do with quilt and git can be done easily with pure git.
> A simple git merge-base can tell you the forked point
> of Android branch. For example, to find the commit
> from which android-2.6.29 forked:
>
> git merge-base v2.6.29 korg/android-2.6.29
I started a project to extract the android features into
patches for an OMAP board I'm working on, but got sidetracked.
I started with a monolithic patch against mainline, and broke
things down by splitting it into patches along feature boundaries.
Maybe it would be easier to start with the git commits and work my
way up (merging commits instead of dividing patches).
Thanks for the info.
-- Tim
>
> On 1月6日, 上午4時56分, Tim Bird <tim.b...@am.sony.com> wrote:
>> noamtm wrote:
>> I have heard rumors of people saying they would make separate patches
>> available, but after looking myself I couldn't find anything. As
>> far as I know, the only way to get a kernel with the required Android
>> features is to use one from an existing Android-based git repository.
=============================
Chih-Wei
> Chih-Wei wrote:
> > All the patches (changes) are available in Android kernel git
> > repository.
> > Why can't you find it?
>
> I mentioned "separate patches". A series of patches extracted
> from git commits is not as easy to work with as a set of
> patches that are maintained along feature boundaries.
Well, it's just a single command to generate this set of patches
from git repo. See man git-format-patch.
$ git format-patch v2.6.29
> I'm mildly surprised that Google doesn't manage their patches
> against mainline in this format, rather than raw git format.
I won't be surprised. If everyone can work on git repo direcrly,
why bother to generate such patches?
> In my experience, it's a good format for managing patches which for
> one reason or another don't end up getting mainlined.
> But then again, I'm not a git expert, and maybe everything
> I do with quilt and git can be done easily with pure git.
Indeed. Working on git repo directly is much easier
than managing many separate patches --
once you get more familiar with git.
> I started a project to extract the android features into
> patches for an OMAP board I'm working on, but got sidetracked.
> I started with a monolithic patch against mainline, and broke
> things down by splitting it into patches along feature boundaries.
> Maybe it would be easier to start with the git commits and work my
> way up (merging commits instead of dividing patches).
Yes.
I have an old blog that describes my experiences to
merge kernel tree from my chipset vendor and
the android kernel.
http://cwhuang.info/2009/06/an-experience-of-git-rebase
(but in Chinese only, sorry)
Tim Bird
> On 1月12日, 上午5時57分, Tim Bird <tim.b...@am.sony.com> wrote:
>> Chih-Wei wrote:
>>> All the patches (changes) are available in Android kernel git
>>> repository.
>>> Why can't you find it?
>> I mentioned "separate patches". A series of patches extracted
>> from git commits is not as easy to work with as a set of
>> patches that are maintained along feature boundaries.
>
> Well, it's just a single command to generate this set of patches
> from git repo. See man git-format-patch.
>
> $ git format-patch v2.6.29
Chih-Wei,
I think you are not understanding me at all. That command
would not in the slightest generate what I am talking about.
>> I'm mildly surprised that Google doesn't manage their patches
>> against mainline in this format, rather than raw git format.
>
> I won't be surprised. If everyone can work on git repo direcrly,
> why bother to generate such patches?
Not everyone can work on a git repo directly. For people whose
starting trees (e.g. from their silicon vendor) on not in git format,
it's, IMHO, easier to work with patches than with git. Apparently
you've had a different experience than me.
> I have an old blog that describes my experiences to
> merge kernel tree from my chipset vendor and
> the android kernel.
>
> http://cwhuang.info/2009/06/an-experience-of-git-rebase
> (but in Chinese only, sorry)
I'll take a look and see if I can learn from your experience.
(if Google can translate it in some manner...)
Thanks,
-- Tim