Bug 1989

Summary: Default module selections need attention
Product: [Build System, Metadata & Runtime] BSPs Reporter: Paul Eggleton <bluelightning>
Component: bsps-configurationAssignee: Bruce Ashfield <bruce.ashfield>
Status: RESOLVED FIXED QA Contact:
Severity: minor    
Priority: Medium+ CC: alexandru.c.georgescu, dvhart, jessica.zhang, richard.purdie, sgw, yp.bsp.watcher, yp.watcher
Version: unspecified   
Target Milestone: 2.2 M4   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: Unknown (Hard to categorize)
Verified: Documentation change: No (bug/feature does not impact docs)

Description Paul Eggleton 2012-02-16 02:26:42 UTC
task-base-extended pulls in kernel-modules, which will pull in all module packages for kernel modules that have been built. As a result we get things like 
ocfs2 and reiserfs installed, which we almost certainly don't need and significantly increase our default image sizes.

This does not affect core-image-minimal (which does not include task-base-extended) however, you can get an idea of the effect on core-image-sato by looking at installed-package-sizes.txt for it in buildhistory:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-buildhistory/tree/images/beagleboard/eglibc/core-image-sato/installed-package-sizes.txt?h=nightly-arm

We should be more selective about the module packages we pull in as part of task-base-extended (perhaps by removing kernel-modules and instead using mechanisms such as MACHINE_EXTRA_RRECOMMENDS) and may wish to consider modifying the module selections in the kernel configuration.
Comment 1 Bruce Ashfield 2012-02-17 13:55:05 UTC
post 1.2 seems appropriate for this. I'll be looking into this anyway for
activities that happen in the future.

For 1.2, we will be tuning the configs for the base/standard/default
path, which means that you will get fewer modules in general.

I'd prefer to not control this (completely) via the board configs in the
kernel itself, since driving packaging issues/concerns into the tree
isn't quite where we want them. Since we re-use the tree in several places
and ways.

Using the MACHINES variables seems reasonable to me.
Comment 2 Bruce Ashfield 2012-05-03 12:57:44 UTC
sized. This can be a sub task of the configuration policy audit for 1.3
Comment 3 Bruce Ashfield 2013-01-16 04:35:43 UTC
Moving to M4, where we'll introduce the release candiate kernel version.
Comment 4 Bruce Ashfield 2013-06-12 15:06:42 UTC
Bumping the milestone to reflect reality. This work will happen on the 3.10+ kernel.
Comment 5 Bruce Ashfield 2013-10-09 00:23:18 UTC
Moving to 1.6, this was partially done in 1.5, but not enough to close the bug in good faith.
Comment 6 Bruce Ashfield 2014-03-06 19:35:58 UTC
Logging more items (we'll call these phase2):

 LTP tests,
 IO tests
 Concurrency tests
 RT  jitter and latency tests 
 Fault injection test drivers
 IP block PnP tests 
 Power management tests, RTPM and Legacy PM
 Platform "ABI" tests  (DMI, SMBios, AML correctness and introspection)
 Pretty much any burn in or Power On test case and common performance KPI.
Comment 7 Darren Hart 2014-03-06 20:56:09 UTC
(In reply to comment #6)
> Logging more items (we'll call these phase2):
> 
>  LTP tests,
>  IO tests
>  Concurrency tests
>  RT  jitter and latency tests 
>  Fault injection test drivers
>  IP block PnP tests 
>  Power management tests, RTPM and Legacy PM
>  Platform "ABI" tests  (DMI, SMBios, AML correctness and introspection)
>  Pretty much any burn in or Power On test case and common performance KPI.

Maybe you intended this for Bug 5569?
Comment 8 Bruce Ashfield 2014-03-06 20:58:45 UTC
Argh. Yes, fixing the case.

(In reply to comment #7)
> (In reply to comment #6)
> > Logging more items (we'll call these phase2):
> > 
> >  LTP tests,
> >  IO tests
> >  Concurrency tests
> >  RT  jitter and latency tests 
> >  Fault injection test drivers
> >  IP block PnP tests 
> >  Power management tests, RTPM and Legacy PM
> >  Platform "ABI" tests  (DMI, SMBios, AML correctness and introspection)
> >  Pretty much any burn in or Power On test case and common performance KPI.
> 
> Maybe you intended this for Bug 5569?
Comment 9 Bruce Ashfield 2014-05-21 14:58:43 UTC
Moving this to 1.7, since we'll be doing this as part of "developer experience"
Comment 10 Richard Purdie 2014-06-13 15:34:17 UTC
I was surprised to see minix.ko even getting built for qemuppc...
Comment 11 Bruce Ashfield 2014-06-13 16:53:11 UTC
(In reply to comment #10)
> I was surprised to see minix.ko even getting built for qemuppc...

Indeed. There's a wholesale purge and changing of the default configuration that is
being scripted as the first pass in cleaning up the options.  Only the hardcore minix
users need to turn that back on ;)
Comment 12 Bruce Ashfield 2016-02-08 21:58:27 UTC
This is dependent on the linux-yocto re-factoring that is currently on review on the mailing list. When that merges, this can complete. The timeline is still TBD for that, since the patches are only in review.
Comment 13 Bruce Ashfield 2016-03-21 23:18:07 UTC
We've done all the factoring that is intended for the 2.1 release, moving this to 2.2 where we'll continue to work on this and have more incremental updates under this bug number.
Comment 14 Bruce Ashfield 2016-09-20 12:36:43 UTC
I'll do one more quick pass on this, and if nothing obvious jumps out, I'll close this and re-open more specific ones for future releases.
Comment 15 Bruce Ashfield 2016-09-22 16:14:33 UTC
putting the milestone where it was supposed to be :D
Comment 16 Bruce Ashfield 2016-10-17 17:02:20 UTC
We've gone as far as planned for this in the 2.2 cycle. New bugs will be opened to track meta data updates in the future.