kernel-dev: Reorganized Kernel Metadata Location and Syntax sections
It seems that the two sections "Kernel Metadata Location" and "Kernel Metadata Syntax" were flipped regarding their order of apperance in the kernel-dev manual. I belive that syntax should be first and then followed by a discussion on the location. I have swapped these section's ordering in the manual. (From yocto-docs rev: 167b088f459c7128bdc1abddd0b948be8f3bf5fe) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
3f06074a0d
commit
d9f2938921
|
@ -170,175 +170,6 @@
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='kernel-metadata-location'>
|
|
||||||
<title>Kernel Metadata Location</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Kernel Metadata always exists outside of the kernel tree either
|
|
||||||
defined in a kernel recipe (recipe-space) or outside of the recipe.
|
|
||||||
Where you choose to define the Metadata depends on what you want
|
|
||||||
to do and how you intend to work.
|
|
||||||
Regardless of where you define the kernel Metadata, the syntax used
|
|
||||||
applies equally.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
If you are unfamiliar with the Linux kernel and only wish
|
|
||||||
to apply a configuration and possibly a couple of patches provided to
|
|
||||||
you by others, the recipe-space method is recommended.
|
|
||||||
This method is also a good approach if you are working with Linux kernel
|
|
||||||
sources you do not control or if you just do not want to maintain a
|
|
||||||
Linux kernel Git repository on your own.
|
|
||||||
For partial information on how you can define kernel Metadata in
|
|
||||||
the recipe-space, see the
|
|
||||||
"<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
|
|
||||||
section.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Conversely, if you are actively developing a kernel and are already
|
|
||||||
maintaining a Linux kernel Git repository of your own, you might find
|
|
||||||
it more convenient to work with kernel Metadata kept outside the
|
|
||||||
recipe-space.
|
|
||||||
Working with Metadata in this area can make iterative development of
|
|
||||||
the Linux kernel more efficient outside of the BitBake environment.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<section id='recipe-space-metadata'>
|
|
||||||
<title>Recipe-Space Metadata</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
When stored in recipe-space, the kernel Metadata files reside in a
|
|
||||||
directory hierarchy below
|
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>.
|
|
||||||
For a linux-yocto recipe or for a Linux kernel recipe derived
|
|
||||||
by copying and modifying
|
|
||||||
<filename>oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb</filename>
|
|
||||||
to a recipe in your layer, <filename>FILESEXTRAPATHS</filename>
|
|
||||||
is typically set to
|
|
||||||
<filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>.
|
|
||||||
See the "<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
|
|
||||||
section for more information.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Here is an example that shows a trivial tree of kernel Metadata
|
|
||||||
stored in recipe-space within a BSP layer:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
meta-<replaceable>my_bsp_layer</replaceable>/
|
|
||||||
`-- recipes-kernel
|
|
||||||
`-- linux
|
|
||||||
`-- linux-yocto
|
|
||||||
|-- bsp-standard.scc
|
|
||||||
|-- bsp.cfg
|
|
||||||
`-- standard.cfg
|
|
||||||
</literallayout>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
When the Metadata is stored in recipe-space, you must take
|
|
||||||
steps to ensure BitBake has the necessary information to decide
|
|
||||||
what files to fetch and when they need to be fetched again.
|
|
||||||
It is only necessary to specify the <filename>.scc</filename>
|
|
||||||
files on the
|
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
|
|
||||||
BitBake parses them and fetches any files referenced in the
|
|
||||||
<filename>.scc</filename> files by the <filename>include</filename>,
|
|
||||||
<filename>patch</filename>, or <filename>kconf</filename> commands.
|
|
||||||
Because of this, it is necessary to bump the recipe
|
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
|
|
||||||
value when changing the content of files not explicitly listed
|
|
||||||
in the <filename>SRC_URI</filename>.
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id='metadata-outside-the-recipe-space'>
|
|
||||||
<title>Metadata Outside the Recipe-Space</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
When stored outside of the recipe-space, the kernel Metadata
|
|
||||||
files reside in a separate repository.
|
|
||||||
The OpenEmbedded build system adds the Metadata to the build as
|
|
||||||
a "ktype=meta" repository through the
|
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
|
||||||
variable.
|
|
||||||
As an example, consider the following <filename>SRC_URI</filename>
|
|
||||||
statement from the <filename>linux-yocto_4.4.bb</filename>
|
|
||||||
kernel recipe:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; \
|
|
||||||
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
|
|
||||||
</literallayout>
|
|
||||||
<filename>${KMETA}</filename>, in this context, is simply used to
|
|
||||||
name the directory into which the Git fetcher places the Metadata.
|
|
||||||
This behavior is no different than any multi-repository
|
|
||||||
<filename>SRC_URI</filename> statement used in a recipe.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
You can keep kernel Metadata in a "kernel-cache", which is a
|
|
||||||
directory containing configuration fragments.
|
|
||||||
As with any Metadata kept outside the recipe-space, you simply
|
|
||||||
need to use the <filename>SRC_URI</filename> statement with the
|
|
||||||
"type=kmeta" attribute.
|
|
||||||
Doing so makes the kernel Metadata available during the
|
|
||||||
configuration phase.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<!--
|
|
||||||
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Following is an example that shows how a trivial tree of Metadata
|
|
||||||
is stored in a custom Linux kernel Git repository:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
meta/
|
|
||||||
`‐‐ cfg
|
|
||||||
`‐‐ kernel-cache
|
|
||||||
|‐‐ bsp-standard.scc
|
|
||||||
|‐‐ bsp.cfg
|
|
||||||
`‐‐ standard.cfg
|
|
||||||
</literallayout>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
To use a branch different from where the sources reside,
|
|
||||||
specify the branch in the <filename>KMETA</filename> variable
|
|
||||||
in your Linux kernel recipe.
|
|
||||||
Here is an example:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
KMETA = "meta"
|
|
||||||
</literallayout>
|
|
||||||
To use the same branch as the sources, set
|
|
||||||
<filename>KMETA</filename> to an empty string:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
KMETA = ""
|
|
||||||
</literallayout>
|
|
||||||
If you are working with your own sources and want to create an
|
|
||||||
orphan <filename>meta</filename> branch, use these commands
|
|
||||||
from within your Linux kernel Git repository:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
$ git checkout ‐‐orphan meta
|
|
||||||
$ git rm -rf .
|
|
||||||
$ git commit ‐‐allow-empty -m "Create orphan meta branch"
|
|
||||||
</literallayout>
|
|
||||||
</para>
|
|
||||||
-->
|
|
||||||
|
|
||||||
<para>
|
|
||||||
If you modify the Metadata, you must not forget to update the
|
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>
|
|
||||||
statements in the kernel's recipe.
|
|
||||||
In particular, you need to update the
|
|
||||||
<filename>SRCREV_meta</filename> variable to match the commit in
|
|
||||||
the <filename>KMETA</filename> branch you wish to use.
|
|
||||||
Changing the data in these branches and not updating the
|
|
||||||
<filename>SRCREV</filename> statements to match will cause the
|
|
||||||
build to fetch an older commit.
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id='kernel-metadata-syntax'>
|
<section id='kernel-metadata-syntax'>
|
||||||
<title>Kernel Metadata Syntax</title>
|
<title>Kernel Metadata Syntax</title>
|
||||||
|
|
||||||
|
@ -884,6 +715,175 @@
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
<section id='kernel-metadata-location'>
|
||||||
|
<title>Kernel Metadata Location</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Kernel Metadata always exists outside of the kernel tree either
|
||||||
|
defined in a kernel recipe (recipe-space) or outside of the recipe.
|
||||||
|
Where you choose to define the Metadata depends on what you want
|
||||||
|
to do and how you intend to work.
|
||||||
|
Regardless of where you define the kernel Metadata, the syntax used
|
||||||
|
applies equally.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If you are unfamiliar with the Linux kernel and only wish
|
||||||
|
to apply a configuration and possibly a couple of patches provided to
|
||||||
|
you by others, the recipe-space method is recommended.
|
||||||
|
This method is also a good approach if you are working with Linux kernel
|
||||||
|
sources you do not control or if you just do not want to maintain a
|
||||||
|
Linux kernel Git repository on your own.
|
||||||
|
For partial information on how you can define kernel Metadata in
|
||||||
|
the recipe-space, see the
|
||||||
|
"<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
|
||||||
|
section.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Conversely, if you are actively developing a kernel and are already
|
||||||
|
maintaining a Linux kernel Git repository of your own, you might find
|
||||||
|
it more convenient to work with kernel Metadata kept outside the
|
||||||
|
recipe-space.
|
||||||
|
Working with Metadata in this area can make iterative development of
|
||||||
|
the Linux kernel more efficient outside of the BitBake environment.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<section id='recipe-space-metadata'>
|
||||||
|
<title>Recipe-Space Metadata</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
When stored in recipe-space, the kernel Metadata files reside in a
|
||||||
|
directory hierarchy below
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>.
|
||||||
|
For a linux-yocto recipe or for a Linux kernel recipe derived
|
||||||
|
by copying and modifying
|
||||||
|
<filename>oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb</filename>
|
||||||
|
to a recipe in your layer, <filename>FILESEXTRAPATHS</filename>
|
||||||
|
is typically set to
|
||||||
|
<filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>.
|
||||||
|
See the "<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
|
||||||
|
section for more information.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Here is an example that shows a trivial tree of kernel Metadata
|
||||||
|
stored in recipe-space within a BSP layer:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
meta-<replaceable>my_bsp_layer</replaceable>/
|
||||||
|
`-- recipes-kernel
|
||||||
|
`-- linux
|
||||||
|
`-- linux-yocto
|
||||||
|
|-- bsp-standard.scc
|
||||||
|
|-- bsp.cfg
|
||||||
|
`-- standard.cfg
|
||||||
|
</literallayout>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
When the Metadata is stored in recipe-space, you must take
|
||||||
|
steps to ensure BitBake has the necessary information to decide
|
||||||
|
what files to fetch and when they need to be fetched again.
|
||||||
|
It is only necessary to specify the <filename>.scc</filename>
|
||||||
|
files on the
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
|
||||||
|
BitBake parses them and fetches any files referenced in the
|
||||||
|
<filename>.scc</filename> files by the <filename>include</filename>,
|
||||||
|
<filename>patch</filename>, or <filename>kconf</filename> commands.
|
||||||
|
Because of this, it is necessary to bump the recipe
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
|
||||||
|
value when changing the content of files not explicitly listed
|
||||||
|
in the <filename>SRC_URI</filename>.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section id='metadata-outside-the-recipe-space'>
|
||||||
|
<title>Metadata Outside the Recipe-Space</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
When stored outside of the recipe-space, the kernel Metadata
|
||||||
|
files reside in a separate repository.
|
||||||
|
The OpenEmbedded build system adds the Metadata to the build as
|
||||||
|
a "ktype=meta" repository through the
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||||||
|
variable.
|
||||||
|
As an example, consider the following <filename>SRC_URI</filename>
|
||||||
|
statement from the <filename>linux-yocto_4.4.bb</filename>
|
||||||
|
kernel recipe:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; \
|
||||||
|
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
|
||||||
|
</literallayout>
|
||||||
|
<filename>${KMETA}</filename>, in this context, is simply used to
|
||||||
|
name the directory into which the Git fetcher places the Metadata.
|
||||||
|
This behavior is no different than any multi-repository
|
||||||
|
<filename>SRC_URI</filename> statement used in a recipe.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
You can keep kernel Metadata in a "kernel-cache", which is a
|
||||||
|
directory containing configuration fragments.
|
||||||
|
As with any Metadata kept outside the recipe-space, you simply
|
||||||
|
need to use the <filename>SRC_URI</filename> statement with the
|
||||||
|
"type=kmeta" attribute.
|
||||||
|
Doing so makes the kernel Metadata available during the
|
||||||
|
configuration phase.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<!--
|
||||||
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Following is an example that shows how a trivial tree of Metadata
|
||||||
|
is stored in a custom Linux kernel Git repository:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
meta/
|
||||||
|
`‐‐ cfg
|
||||||
|
`‐‐ kernel-cache
|
||||||
|
|‐‐ bsp-standard.scc
|
||||||
|
|‐‐ bsp.cfg
|
||||||
|
`‐‐ standard.cfg
|
||||||
|
</literallayout>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
To use a branch different from where the sources reside,
|
||||||
|
specify the branch in the <filename>KMETA</filename> variable
|
||||||
|
in your Linux kernel recipe.
|
||||||
|
Here is an example:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
KMETA = "meta"
|
||||||
|
</literallayout>
|
||||||
|
To use the same branch as the sources, set
|
||||||
|
<filename>KMETA</filename> to an empty string:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
KMETA = ""
|
||||||
|
</literallayout>
|
||||||
|
If you are working with your own sources and want to create an
|
||||||
|
orphan <filename>meta</filename> branch, use these commands
|
||||||
|
from within your Linux kernel Git repository:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
$ git checkout ‐‐orphan meta
|
||||||
|
$ git rm -rf .
|
||||||
|
$ git commit ‐‐allow-empty -m "Create orphan meta branch"
|
||||||
|
</literallayout>
|
||||||
|
</para>
|
||||||
|
-->
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If you modify the Metadata, you must not forget to update the
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>
|
||||||
|
statements in the kernel's recipe.
|
||||||
|
In particular, you need to update the
|
||||||
|
<filename>SRCREV_meta</filename> variable to match the commit in
|
||||||
|
the <filename>KMETA</filename> branch you wish to use.
|
||||||
|
Changing the data in these branches and not updating the
|
||||||
|
<filename>SRCREV</filename> statements to match will cause the
|
||||||
|
build to fetch an older commit.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section id='organizing-your-source'>
|
<section id='organizing-your-source'>
|
||||||
<title>Organizing Your Source</title>
|
<title>Organizing Your Source</title>
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue