[linux-yocto] Locating kernel metadata

[Peter A. Bigot]

I want the ability to have a BSP layer linux-yocto_3.10.bbappend which 
supports a new machine by providing a BSP scc file and some BSP-specific 
overrides in recipe space that re-use and where necessary override 
features that exist in the standard meta hierarchy.  There is some 
previous discussion of this at [1] and [2].  What remains unclear to me 
are two issues:

1) how to specify and prioritize the search directories for metadata 
material (patches, fragments, features, kernel types);

2) how to identify the file containing the material within a directive 
(viz., with or without a path relative to a root search directory);

There are two search directories documented:

* "in-tree" which ends up as ${S}/.meta/cfg/kernel-cache through tool 
magic guided by KMETA (where the directory name .meta is derived from 
the branch identified by ${KMETA})

* "recipe-space" which ends up as ${WORKDIR} for material identified in 
the SRC_URI of a recipe

Earlier documentation assumed that only one or the other is used, but 
since recipe-space material can now reference in-tree material a 
priority needs to be defined.

Now: within an scc file you can do:

    include features/media/media-camera.scc

and that file in turn can do:

    kconf media-camera.cfg

which resolves automatically to features/media/media-camera.cfg. This 
reveals that there is also a third search directory: the "current 
directory".  Is that the directory in which the fragment that contains 
the directive is found?  What is its priority relative to the 
recipe-space and in-tree metadata roots?

I believe that in the past fragment file names that did not include a 
path could be located anywhere under the kernel-cache directory (e.g., 
in cfg, features, patches, ktypes, or even bsp). What if 
media-camera.cfg did not exist in the "current directory" or the root of 
any search directory; should it be found if present in a subdirectory?  
If so the namespace gets flattened and as more BSPs add their metadata 
to the Yocto standard one the likelihood of collision and 
incompatibility increases.

That last observation identifies a potential fourth directory: The 
directory containing the master BSP description file (the one with 
KMACHINE/KTYPE/KARCH).  By explicitly calling out this directory any 
files in kernel-cache/bsp/* that belong to other BSPs will be ignored, 
and media-camera.cfg can be overridden for a specific machine without 
having to replicate media-camera.scc.

To make kernel metadata deterministic it would be necessary to provide a 
mechanism to prioritize these four search directories, and perhaps also 
to change the algorithm so that unqualified files (no path) will not be 
found in subdirectories of these directories.

Comments and discussion?

Peter

[1] http://article.gmane.org/gmane.comp.handhelds.openembedded.core/41298/
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=5090