[gnome-continuous-yocto/gnomeostree-3.28-rocko: 5312/8267] kernel-dev: Reorganized Kernel Metadata Location and Syntax sections
- From: Emmanuele Bassi <ebassi src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gnome-continuous-yocto/gnomeostree-3.28-rocko: 5312/8267] kernel-dev: Reorganized Kernel Metadata Location and Syntax sections
- Date: Sun, 17 Dec 2017 03:15:47 +0000 (UTC)
commit d9f293892174ffb8a7c3e3dc23e58f4ba1b09ee4
Author: Scott Rifenbark <srifenbark gmail com>
Date: Tue Mar 21 12:52:09 2017 -0700
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>
documentation/kernel-dev/kernel-dev-advanced.xml | 338 +++++++++++-----------
1 files changed, 169 insertions(+), 169 deletions(-)
---
diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml
b/documentation/kernel-dev/kernel-dev-advanced.xml
index 266ef3a..1c1b636 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -170,175 +170,6 @@
</para>
</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'>
<title>Kernel Metadata Syntax</title>
@@ -884,6 +715,175 @@
</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'>
<title>Organizing Your Source</title>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
