Bug 10416

Summary: Extensible SDK: provide easy means of reconfiguring the kernel
Product: [Yocto Project Subprojects] eSDK Reporter: Paul Eggleton <bluelightning>
Component: eSDKAssignee: chandana kalluri <ckalluri>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: Medium+ CC: alejandr, david.reyna, jose.perez.carranza, juan.m.cruz.alcaraz, leonardo.sandoval.gonzalez, libertad.gonzalez.de.la.cruz, randy.macleod, richard.purdie
Version: unspecified   
Target Milestone: 2.8 M2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Yes (doc changes required)

Description Paul Eggleton 2016-10-12 02:05:12 UTC 
If you wish to customise the kernel configuration within the eSDK there's really no choice other than running devtool modify which checks out the entire source tree. However this has quite a bit of overhead in time and space when all you want to do is run "make menuconfig" and keep the kernel configuration somewhere.

I did a basic implementation of something for this in Ostro, however this basically just does a devtool modify internally, hence why I didn't push it into OE-Core:

https://github.com/ostroproject/meta-ostro/blob/master/meta-ostro/lib/devtool/kconfig.py

To support this it seems to me we need the ability to have the kernel "in" the workspace (in order to have somewhere to save the config) but not be using externalsrc.
Comment 1 Juan Manuel Cruz Alcaraz 2017-04-26 20:27:22 UTC 
As I understand, the issue with the current proposal is the poor performance because the entire kernel source tree is checked out.

To be able to use menuconfig the user must have the complete kernel tree with all the Kconfig database in place. To edit a defconfig file the user needs all the Kconfig files, otherwise there is no way to know the interdependencies among the configuration symbols.


Can you help clarify what is the meaning to have the kernel "in" the workspace versus externalsrc and how it improves the execution?
Comment 2 Juan Manuel Cruz Alcaraz 2017-06-23 21:25:54 UTC 
If running a "devtool kernel-menuconfig" inside a eSDK installation and after executing a command "standard._run_task(tinfoil, fn, 'patch')" the following errors appear:

ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus 997de1272b220be7444b29274fe9a887 for /home/yocto/poky_sdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus 997de1272b220be7444b29274fe9a887 for /home/yocto/poky_sdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack

The "tinfoil.config_data.setVar('BB_HASH_IGNORE_MISMATCH', '1')" is set.

If running "devtool modify linux-yocto" the same taskhash mismatch errors appear.

This errors do not happen if "devtool modify linux-yocto" is run inside a poky folder. It leads me to think that the errors happen because an error on my eSDK installation or an internal bug with the eSDL installation.

I'll keep investigating and update accordingly.
Comment 3 Juan Manuel Cruz Alcaraz 2017-08-24 16:29:24 UTC 
After a short chat with Paul we decided that the approach taken on the first patch sent to review was not the best one.

The first patch intended to share the kernel code with the code fetched by "devtool modify virtual/kernel" in the workspace.

The new approach will share the kernel code fetched by a "bitbake menu-config" command in the workdir.
Comment 4 Alejandro Hernandez 2018-08-23 20:41:49 UTC 
This should also work for other components that use Kconfig, e.g. busybox.
Comment 5 Richard Purdie 2019-02-28 16:21:14 UTC 
Thanks for the patches!

We currently have tests for devtool which are run with "oe-selftest -r devtool", they're in meta/lib/oeqa/selftest/cases/devtool.py. Would you be able to add some tests for this new functionality?
Comment 6 David Reyna 2019-05-18 00:22:34 UTC 
Paul Eggleton will be reviewing the patches shortly.