On 16 September 2011 10:55, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
Just my 2 cents.
On Thu, 15 Sep 2011 16:13:32 -0500 Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 15 September 2011 15:58, James Westby james.westby@linaro.org wrote:
On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used.
How is it chore? You get uImage out of boot.tar.bz2 and run scripts/extract-ikconfig from kernel tree on it, voila.
Sure, and that's a valid usecase, but I'm really just looking for a script that has all the links already in it that someone could run or run with minor modification.
As long as we have CONFIG_IKCONFIG_PROC in defconfig, we're ok, and every (open) kernel in the world has to have that option on. Btw, I was really astonished to find out that Ubuntu doesn't have that option set. Horror! My noname cheap tablet doesn't conceal its kernel config from me, and Ubuntu does.
John, Andy, Angus, Bernhard, Mathieu would you turn on CONFIG_IKCONFIG_PROC in your configs?
I thought, it may make sense to provide an
way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts?
Hi,
We could (fairly easily I imagine) make the actual config an artefact of the build. Then you could go to any build, grab the config, and so build the same thing locally.
Passing it in would be ok, but I'm not sure we would want to make every build have the config specified as well as everything else? The only way that it would be universal would be if you had to specify this on every config, which seems to duplicate information inside the tree.
Providing the config that was used as an artefact would be universal. I guess we even have a choice between providing the full .config, and just the name of the defconfig, if that's how the Android build system selects them.
It just does it by name.
Thinking more about this.
Replacing a kernel is a pretty normal operation.
It's normal operation for those who know how to do that. And giving people who don't know a script doesn't help at all, because very next question will be "I get error running your script, wazzup?", next one will be "I made some random changes to defconfig and it no longer boots", etc, etc.
Sure, that's actually okay. That would be a good email because people would be working with our stuff and we could help them out etc.
I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like:
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-li...
tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2
make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig && make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage
Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds.
I am usually proponent of providing more information about builds (and introspection into systems in general), but that seems a bit too much/misplaced to me. First of all, kernel is of course a bit special, but there're thousand other components in Android which might be good to replace, so what about providing 1K scripts to handle that? With that in mind, for me, threshold for how many such scripts to provide is at 0, not 1.
Sure, but we'd just do the kernel.
Secondly, kernel, while special, is still integral component of Android, so our job is to provide the best kernel and its config, and those who need to tweak/replace it, need to already know how to do that, or learn their way thru it. And that knowledge is not Android-specific, as argued above, and as argued above, providing "shortcuts" for that would be more of disservice. YMMV ;-)
I don't think so. The script would have all the commands in it so it would help people make this leap while lowering the burden on our team to answer each email with the steps that would be in the scripts.
Thanks,
James
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog