We need to clearly document kernel policy and make the config fragments reflect it. This will facilitate a more modular approach to building BSP kernel configs, as well as make it clear what can be expected to be supported when running a "linux-yocto kernel".
To be clear, this involves a tedious audit of all configuration options and existing fragments for all BSPs to refactor them into something that clearly separates policy from hardware while at the same time provides enough flexibility to build both tiny, standard, preempt-rt, and potentially other flavors for linux-yocto.
This is also covered in: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1644
(In reply to comment #2) > This is also covered in: > > http://bugzilla.yoctoproject.org/show_bug.cgi?id=1644 We sized 1644 on just defining use cases - not on making fragment changes. Sizing included in this bug for that.
This is going to get bumped to the 1.3 release. Things work as they are, they just aren't as clearly articulated and divided up as would be ideal.
Resizing as some of this has been done in 3.2.
Marked as P1, time we get this done. Fits with 1.3 goals.
Bruce will be adding a README to the top of the meta directory which defines the intended policy of the ktypes in English, and then describes rules of thumb to help people make the decisions of what are policy, arch, feature, and bsp appropriate config changes. With the README in place, this bug can be closed.
since this is documentation only, I've moved it to M3.
Draft is available: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/commit/?id=ebeedbaac16b02fe03fa153bb35dba79187e5302
Updated with Darren's comments: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/commit/?id=db7176aea805706392e225fa655ba01d85baaa2d Marking this as resolved. More updates will follow, but the goal has been met.
Verified. yocto-kernel-cache: master/863e44aa1ca31ffaa70da15a13b9e9cd7da0cc9f