1989 2012-02-16 02:26:42 +0000 Default module selections need attention 2016-10-17 17:02:20 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-configuration unspecified All Multiple RESOLVED FIXED Medium+ minor 2.2 M4 1 bluelightning bruce.ashfield alexandru.c.georgescu dvhart jessica.zhang richard.purdie sgw yp.bsp.watcher yp.watcher --- Unknown (Hard to categorize) No (bug/feature does not impact docs) oldest_to_newest 18623 0 bluelightning 2012-02-16 02:26:42 +0000 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. 18650 1 bruce.ashfield 2012-02-17 13:55:05 +0000 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. 21058 2 bruce.ashfield 2012-05-03 12:57:44 +0000 sized. This can be a sub task of the configuration policy audit for 1.3 28843 3 bruce.ashfield 2013-01-16 04:35:43 +0000 Moving to M4, where we'll introduce the release candiate kernel version. 33867 4 bruce.ashfield 2013-06-12 15:06:42 +0000 Bumping the milestone to reflect reality. This work will happen on the 3.10+ kernel. 37757 5 bruce.ashfield 2013-10-09 00:23:18 +0000 Moving to 1.6, this was partially done in 1.5, but not enough to close the bug in good faith. 40944 6 bruce.ashfield 2014-03-06 19:35:58 +0000 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. 40945 7 dvhart 2014-03-06 20:56:09 +0000 (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? 40946 8 bruce.ashfield 2014-03-06 20:58:45 +0000 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? 43451 9 bruce.ashfield 2014-05-21 14:58:43 +0000 Moving this to 1.7, since we'll be doing this as part of "developer experience" 43945 10 richard.purdie 2014-06-13 15:34:17 +0000 I was surprised to see minix.ko even getting built for qemuppc... 43952 11 bruce.ashfield 2014-06-13 16:53:11 +0000 (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 ;) 58749 12 bruce.ashfield 2016-02-08 21:58:27 +0000 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. 60237 13 bruce.ashfield 2016-03-21 23:18:07 +0000 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. 66357 14 bruce.ashfield 2016-09-20 12:36:43 +0000 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. 66505 15 bruce.ashfield 2016-09-22 16:14:33 +0000 putting the milestone where it was supposed to be :D 67300 16 bruce.ashfield 2016-10-17 17:02:20 +0000 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.