Bug 6658

Summary:	devtool: enable kernel development
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Paul Eggleton <bluelightning>
Component:	devtools / tool chain	Assignee:	Markus Lehtonen <markus.lehtonen>
Status:	RESOLVED FIXED	QA Contact:	Francisco Pedraza <francisco.j.pedraza.gonzalez>
Severity:	enhancement
Priority:	Medium+	CC:	alexandru.c.georgescu, bruce.ashfield, dvhart, francisco.j.pedraza.gonzalez, meta.mr.watcher, meta.watcher
Version:	1.7
Target Milestone:	2.1 M3
Hardware:	All
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Yes (doc changes required)
Bug Depends on:	6653
Bug Blocks:

Description Paul Eggleton 2014-08-24 17:33:35 UTC

Ensure we have whatever we need in place to support kernel development using the tool outlined in bug 6653. This includes but may not be limited to:
* Ensure that externalsrc works properly for the kernel
* Ensure that the appropriate tasks are called when building
* Reduce as much as possible the time taken to build after changes, e.g. ensure compilation is incremental; possibly eliminate module building where appropriate
* Allow access to menuconfig for the kernel (and other recipes that inherit cml1)

(This may obviate bug 2658.)

Comment 1 Markus Lehtonen 2015-04-20 19:13:26 UTC

Handling the kernel configuration nicely is possibly the trickiest part. There are multiple "levels" of support that could be enabled:
1. Changing config in B (builddir), e.g. via menuconfig
2. Store/commit full config in srctree and use that for building
3. Support modifying config via the meta branch

Any opinions? Maybe a separate bug about the config handling would be in order?

Comment 2 Bruce Ashfield 2015-04-21 14:16:16 UTC

(In reply to comment #1)
> Handling the kernel configuration nicely is possibly the trickiest part.
> There are multiple "levels" of support that could be enabled:
> 1. Changing config in B (builddir), e.g. via menuconfig
> 2. Store/commit full config in srctree and use that for building
> 3. Support modifying config via the meta branch
> 
> Any opinions? Maybe a separate bug about the config handling would be in
> order?

Cases #1 and #2 make sense if you find a sane starting configuration. 

For #3, it would be the meta branch, or just use recipe space 
configuration fragments (since they are treated the same by the code).
An easier starting point would be recipe space fragments.

In the end, it would be a good idea to ensure that whatever the tools
support for configuration that we end up producing consistent:

  - base configuration
  - incremental fragments

We can do that for any of the cases above, by saving the original
config, and either directly producing the fragment, or by diffing
against the original. Since this model familiarizes developers with
configuration fragments, and they are something that can easily
be reviewed and made part of a permanent build.

Comment 3 Markus Lehtonen 2015-12-03 14:08:34 UTC

This bug has been a bit forgotten. All the basic support should be there, now, except for the kernel config handling.

I just sent a devtool patch that makes devtool copy kernel .config to the srctree when doing 'extract' operation:
http://lists.openembedded.org/pipermail/openembedded-core/2015-December/113693.html

What do you think, is this a sufficient way to store a base configuration? With this 'devtool update-recipe' could diff the effective configuration in ${S} against this base and add any changes as one monolithic config fragment to the recipe.

Comment 4 Markus Lehtonen 2016-01-29 08:42:33 UTC

I'm closing this now as the basic kernel support has been merged. There is a separate related bug kernel about kernel config handling:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8999

Please re-open if you disagree