On 16 September 2011 10:55, Paul Sokolovsky <paul.sokolov...@linaro.org> wrote: > Hello, > > Just my 2 cents. > > On Thu, 15 Sep 2011 16:13:32 -0500 > Zach Pfeffer <zach.pfef...@linaro.org> wrote: > >> On 15 September 2011 15:58, James Westby <james.wes...@linaro.org> >> wrote: >> > On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer >> > <zach.pfef...@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-linaro-master-with-generic-target/18/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 >> >> 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/#!/linaroorg - http://www.linaro.org/linaro-blog > -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
