mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-04-26 00:32:12 +02:00
Code Issues Packages Projects Releases Wiki Activity

getting-started, dev-manual: Created Layer Model section

Browse Source 
This involved removing the general information about layers from
the dev-manual and incorporating it into the new section of the
getting-started manual.

(From yocto-docs rev: 26438b03751948661f48fb0c023e393101b80e19)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2018-02-12 09:11:37 -08:00
committed by Richard Purdie
parent 4b3ebf00dc
commit cfdf4c78eb
2 changed files with 120 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

118
documentation/getting-started/getting-started-yp-intro.xml
View File

@@ -265,9 +265,123 @@
</section>
</section>
<section id='what-are-layers'>
<title>What are Layers?</title>
<section id='the-yocto-project-layer-model'>
<title>The Yocto Project Layer Model</title>
<para>
The Yocto Project's "Layer Model" is a development model for
embedded and IoT Linux creation that distinguishes the
Yocto Project from other simple build systems.
The Layer Model simultaneously supports collaboration and
customization.
Layers are repositories that contain related sets of instructions
that tell the OpenEmbedded build system what to do.
You can collaborate, share, and reuse layers.
</para>
<para>
Layers can contain changes to previous instructions or settings
at any time.
This powerful override capability is what allows you to customize
previously supplied collaborative or community layers to suit your
product requirements.
</para>
<para>
You use different layers to logically separate information in your
build.
As an example, you could have BSP, GUI, distro configuration,
middleware, or application layers.
Putting your entire build into one layer limits and complicates
future customization and reuse.
Isolating information into layers, on the other hand, helps
simplify future customizations and reuse.
You might find it tempting to keep everything in one layer when
working on a single project.
However, the more modular your Metadata, the easier
it is to cope with future changes.
<note><title>Notes</title>
<itemizedlist>
<listitem><para>
Use Board Support Package (BSP) layers from silicon
vendors when possible.
</para></listitem>
<listitem><para>
Familiarize yourself with the
<ulink url='https://caffelli-staging.yoctoproject.org/software-overview/layers/'>Yocto Project curated layer index</ulink>
or the
<ulink url='http://layers.openembedded.org/layerindex/branch/master/layers/'>OpenEmbedded layer index</ulink>.
The latter contains more layers but they are less
universally validated.
</para></listitem>
<listitem><para>
Layers support the inclusion of technologies, hardware
components, and software components.
The Yocto Project Compatible designation provides a
minimum level of standardization that contributes to a
strong ecosystem.
"YP Compatible" is applied to appropriate products and
software components such as BSPs, other OE-compatible
layers, and related open-source projects, allowing the
producer to use Yocto Project badges and branding
assets.
</para></listitem>
</itemizedlist>
</note>
</para>
<para>
To illustrate how layers are used to keep things modular, consider
machine customizations.
These types of customizations typically reside in a special layer,
rather than a general layer, called a BSP Layer.
Furthermore, the machine customizations should be isolated from
recipes and Metadata that support a new GUI environment,
for example.
This situation gives you a couple of layers: one for the machine
configurations, and one for the GUI environment.
It is important to understand, however, that the BSP layer can
still make machine-specific additions to recipes within the GUI
environment layer without polluting the GUI layer itself
with those machine-specific changes.
You can accomplish this through a recipe that is a BitBake append
(<filename>.bbappend</filename>) file, which is described later
in this section.
<note>
For general information on BSP layer structure, see the
<ulink url='&YOCTO_DOCS_BSP_URL;#bsp'>Board Support Packages (BSP) - Developer's Guide</ulink>.
</note>
</para>
<para>
The
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
contains both general layers and BSP layers right out of the box.
You can easily identify layers that ship with a Yocto Project
release in the Source Directory by their names.
Layers typically have names that begin with the string
<filename>meta-</filename>.
<note>
It is not a requirement that a layer name begin with the
prefix <filename>meta-</filename>, but it is a commonly
accepted standard in the Yocto Project community.
</note>
For example, if you were to examine the
<ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/'>tree view</ulink>
of the <filename>poky</filename> repository, you will see several
layers: <filename>meta</filename>,
<filename>meta-skeleton</filename>,
<filename>meta-selftest</filename>,
<filename>meta-poky</filename>, and
<filename>meta-yocto-bsp</filename>.
Each of these repositories represents a distinct layer.
</para>
<para>
For procedures on how to create layers, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
</section>
<section id='components-and-tools'>