Bug 10470

Summary:	I would like to be able to set kernel CONFIGS from my local.conf file
Product:	[Yocto Project Subprojects] Kernel	Reporter:	brian avery <brian.avery>
Component:	kernel-configuration	Assignee:	Bruce Ashfield <bruce.ashfield>
Status:	RESOLVED INVALID	QA Contact:
Severity:	enhancement
Priority:	Low	CC:	california.l.sullivan, richard.purdie, sgw, tim.orling, yp.kernel.watcher, yp.watcher
Version:	2.3
Target Milestone:	2.3
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Yes (doc changes required)

Description brian avery 2016-10-20 20:36:55 UTC

This is not aimed at production so much as a way to make iterative kernel development easier and less cumbersome.  If I want to turn on something like 

CONFIG_CGROUP_DEVICE=y  

it would be nice to be able to just append it to my local.conf with something like:

KERNEL_CONFIG_append += "CONFIG_CGROUP_DEVICE=y "

Having to make a layer, add a cfg file and bbappends for the kernel version seems to me to be too heavyweight for iterative development/experimentation.

---

I'm not sure if 
KERNEL_CONFIG_append += "# CONFIG_IRQ_POLL is not set " 
or 
KERNEL_CONFIG_append += "CONFIG_IRQ_POLL=n " 

which would automagically convert to  
# CONFIG_IRQ_POLL is not set

is better.

Comment 1 Bruce Ashfield 2016-10-20 20:56:03 UTC

That makes the kernel configuration global, and breaks the encapsulation of the package/recipe.

Not to mention, there's no way to actually have version specific configs that way, and having someone with config values in their local.conf is going to cause all sorts of kernel version skew issues.

Environment variables for this reason also cause similar issues.

This is no different than not setting packageconfigs, or any other recipe/package specific variable from .conf files.

You can always do a _pn manipulation of the SRC_URI in your local.conf (I think), since that makes the variable specific to the kernel package / provider.

For interactive development, there's externalsrc, or simply menuconfig .. providing something like this via the .conf files is a bad idea in general.

I can accept this for now, but it is very unlikely to be implemented.

Comment 2 Richard Purdie 2016-10-27 14:35:10 UTC

Firstly, you don't need another layer, you can do this kind of thing from your build directory if I remember correctly (create a bbappend). Secondly, to Bruce's point, you could use recipe specific overrides in local.conf to make the changes only apply to a specific recipe.

Comment 3 Tim Orling 2016-10-27 14:36:38 UTC

Perhaps we could add a helper in devtool instead.

Comment 4 brian avery 2016-10-28 01:56:19 UTC

So, 
1) Bruce that makes sense and I understand why my wish is wrong.
2) Turns out you can put this in local.conf and it works easily:
------
-- in local.conf --
FILESEXTRAPATHS_prepend_pn-linux-yocto := "/home/cow:"
SRC_URI_append_pn-linux-yocto = " file://myKernelConfigs.cfg "
--  file myKernelConfigs.cfg located in /home/cow --
# Support for virtual ethernet and LXC
CONFIG_VETH=y
CONFIG_MACVLAN=y
# or whatever you want
-------------

So, I''ll go ahead and close this as invalid (correct ?)  and will write a very short tips and tricks for how to do the above and the bbappend way tomorrow.

Comment 5 Bruce Ashfield 2016-10-28 13:12:47 UTC

(In reply to comment #4)
> So, 
> 1) Bruce that makes sense and I understand why my wish is wrong.
> 2) Turns out you can put this in local.conf and it works easily:
> ------
> -- in local.conf --
> FILESEXTRAPATHS_prepend_pn-linux-yocto := "/home/cow:"
> SRC_URI_append_pn-linux-yocto = " file://myKernelConfigs.cfg "
> --  file myKernelConfigs.cfg located in /home/cow --
> # Support for virtual ethernet and LXC
> CONFIG_VETH=y
> CONFIG_MACVLAN=y
> # or whatever you want
> -------------
> 
> So, I''ll go ahead and close this as invalid (correct ?)  and will write a
> very short tips and tricks for how to do the above and the bbappend way
> tomorrow.

That would be ideal. Making sure this is documented in a (relatively) easy to find place helps everyone.

In particular since I'll move the fragment support to be widely available in the 2.3 timeframe, whatever you document will be valid for any kernel type.