Bug 2267

This is hard to get right when the kernel version and options change. Driving it from the BSP
(which knows the hardware) is the right place to do this. i.e. sure the distro can try and add
WIFI, but the BSP knows if that's even possible given the hardware available, so you can't just
always add the support based on a DISTRO flag .. or you can try and be prepared to throw a hard
error if the BSP doesn't support it.

The point is more that there's another way to view this, the BSP should define what it supports,
and the DISTRO features should check against that list and enable if they are valid (and requested).
That means you keep a tight BSP, or a broader one .. or somewhere in between and the distro
can adapt to that .. not vice versa.

You're right - this is a broader issue I'm trying to describe... will think on it and update here.

An interesting thought occurs to me. The kernel policy which we currently define in the various KTYPE might be a more appropriate area of influence for the DISTRO. I can see various angles on this and am tring to see how they fit best.

Consider features like debug, tracing, tuning knobs, various file descriptor support, executable formats, preemption all seem like things that DISTRO policy might like to cover.

Taken far enough, this could eliminate the need for multiple ktypes that differ only in policy - such as "tiny". We would need kernel features that map directly to DISTRO_FEATURES. Some of these could be BSP specific

kernel-cache/features/distro/block.cfg
kernel-cache/bsp/fri2/block.cfg

The first would enable the block layer, the latter would enable the sata controller and usb mass storage. For example.

There is significant overlap with other mechanisms we're trying to support. Thoughts?

FYI: I will respond to this in the case, I'm just trying to work through some other items first.

You are on the right track. kernel types are just a name for a default
collections of options, given a high level name. We still need/want kernel
types as defaults (call them kernel profiles if you want, since it really
is just a name), to provide a default set of working options that are functional
and controlled by a board description. This also keeps the tree standalone
and as a reference.

Assuming that we get the 'base' configuration to a state where it is
an acceptable subset of -rt/standard/tiny, we are set to then create
more building blocks/features within the tree that the distro policy can
use to augment the defaults. Consider the ktypes to be similar to the poky
distro policy on top of oe-core. They are in place, but can be augmented
by another distro.

Elements that are pure policy (like your examples) should definitely be
an area of influence from the distro. It is the grey areas of distro 'policy' that
have hardware requirements .. that the ktypes and BSPs really need to be
in place. They encapsulate what the board supports, and what was tested (plus optional blocks via modules) and keep it up to date with a given kernel,  rather than spreading it throughout the system and having conditionals and bit rot set in.

But yes, eliminating policy only different kernel types should be possible. In fact I should be able to unify all the kernel recipes soon with some OVERRIDES settings.

OK, so definiing KERNEL_FEATURES via the DISTRO definition should be doable. The interesting part though is how do we make this simple from the users' perspective. For example:

DISTRO_FEATURES += "wifi"
...
KERNEL_FEATURES += "features/wifi_80211.scc"

would not be ideal. It would be much nicer if:

DISTRO_FEATURES += "wifi"

could be parsed inside of linux-yocto.inc and automatically translated into features. This is also nice because it doesn't make a hard coupling between a distro definition and the specific kernel features. In fact, we may need to perform this mapping in the versioned linux-yocto kernel recipes as these features are likely to change - although if we keep the names the same and only have to change the .cfg files the .scc files reference, then we could use the include file. It will have to be fault tolerant so that a missing DISTRO=>KERNEL feature mapping results in a warning and doesn't break the build.

Does this approach seem appropriate?

That's pretty close to what I've done in the past.

  - having the mapping to in-tree features in recipes/build system is ok, since
    it keeps the fragments in tree, and individual manipulations of the
    .config and options NOT in build system. version recipe, .inc or data 
    driven class file all work, as long as we don't make the config fragment
    names an ABI. Something that can map to linux-yocto-custom* would be ideal
    as well.

  - The tree has rudimentary query support, which can be exported and used
    to build a list of valid feature options. It's better to query the tree
    live, but remote access is a problem, so exports likely work better.

    That gets you the fragment names, and then can be mapped to any distro
    feature names you want via the routines

  - There still needs to be a hardware override that should optionally stop
    the build, or WARN by default. Since there still has be some capability
    for a board's description (in coordination with the machine.conf file) to
    prevent distro features from enabling hardware functionality that doesn't
    exist or can't work.

    Addon cards are obviously one exception, since the board description can't
    know if they are in .. or not.

Moving to 1.7, will do as part of the developer experience theme.

bumping to 1.9, since this can't make the feature freeze for 1.8.

Bruce, Do you want to keep the defect open or close it after 7 years! :)

It's worth keeping. Simply for when people ask about it, I can ask them to post their use cases here.

The rust-in-kernel feature was implemented along these lines
so it's an example of how we could to this for wifi and other features.