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
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
