diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml index 1290994257..a94ad6fd85 100644 --- a/documentation/kernel-dev/kernel-dev-common.xml +++ b/documentation/kernel-dev/kernel-dev-common.xml @@ -2,388 +2,380 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ %poky; ] > - + -Yocto Project Kernel Concepts +Common Tasks -
- Introduction - - This chapter provides conceptual information about the kernel: - - Kernel Goals - Kernel Development and Maintenance Overview - Kernel Architecture - Kernel Tools - - -
+ + This chapter describes common tasks you need to do when working + on the Yocto Project Linux kernel. + + +
+ Preparing a Layer -
- Kernel Goals - The complexity of embedded kernel design has increased dramatically. - Whether it is managing multiple implementations of a particular feature or tuning and - optimizing board specific features, both flexibility and maintainability are key concerns. - The Linux kernels available through the Yocto Project are presented with the embedded - developer's needs in mind and have evolved to assist in these key concerns. - For example, prior methods such as applying hundreds of patches to an extracted - tarball have been replaced with proven techniques that allow easy inspection, - bisection and analysis of changes. - Application of these techniques also creates a platform for performing integration and - collaboration with the thousands of upstream development projects. - - - With all these considerations in mind, the Yocto Project's kernel and development team - strives to attain these goals: - - Allow the end user to leverage community best practices to seamlessly - manage the development, build and debug cycles. - Create a platform for performing integration and collaboration with the - thousands of upstream development projects that exist. - Provide mechanisms that support many different work flows, front-ends and - management techniques. - Deliver the most up-to-date kernel possible while still ensuring that - the baseline kernel is the most stable official release. - Include major technological features as part of the Yocto Project's - upward revision strategy. - Present a kernel Git repository that, similar to the upstream - kernel.org tree, - has a clear and continuous history. - Deliver a key set of supported kernel types, where each type is tailored - to meet a specific use (e.g. networking, consumer, devices, and so forth). - Employ a Git branching strategy that, from a developer's point of view, - results in a linear path from the baseline kernel.org, - through a select group of features and - ends with their BSP-specific commits. - + Customizing recipes is best done in a layer with bbappend files. Layers also +provide a convenient mechanism to create your own recipes. This guide assumes +you will be working from within a layer independent from those released with the +Yocto Project. For details on how to create and work with layers, refer to +section 5.1 Understanding and Creating Layers in the Yocto Project Development +Manual. + +(Kernel specific directions in 5.7.4)
-
- Yocto Project Kernel Development and Maintenance Overview - - Kernels available through the Yocto Project, like other kernels, are based off the Linux - kernel releases from . - At the beginning of a major development cycle, the Yocto Project team - chooses its kernel based on factors such as release timing, the anticipated release - timing of final upstream kernel.org versions, and Yocto Project - feature requirements. - Typically, the kernel chosen is in the - final stages of development by the community. - In other words, the kernel is in the release - candidate or "rc" phase and not yet a final release. - But, by being in the final stages of external development, the team knows that the - kernel.org final release will clearly be within the early stages of - the Yocto Project development window. - - - This balance allows the team to deliver the most up-to-date kernel - possible, while still ensuring that the team has a stable official release for - the baseline Linux kernel version. - - - The ultimate source for kernels available through the Yocto Project are released kernels - from kernel.org. - In addition to a foundational kernel from kernel.org, the - kernels available contain a mix of important new mainline - developments, non-mainline developments (when there is no alternative), - Board Support Package (BSP) developments, - and custom features. - These additions result in a commercially released Yocto Project Linux kernel that caters - to specific embedded designer needs for targeted hardware. - - - Once a kernel is officially released, the Yocto Project team goes into - their next development cycle, or upward revision (uprev) cycle, while still - continuing maintenance on the released kernel. - It is important to note that the most sustainable and stable way - to include feature development upstream is through a kernel uprev process. - Back-porting hundreds of individual fixes and minor features from various - kernel versions is not sustainable and can easily compromise quality. - - - During the uprev cycle, the Yocto Project team uses an ongoing analysis of - kernel development, BSP support, and release timing to select the best - possible kernel.org version. - The team continually monitors community kernel - development to look for significant features of interest. - The team does consider back-porting large features if they have a significant advantage. - User or community demand can also trigger a back-port or creation of new - functionality in the Yocto Project baseline kernel during the uprev cycle. - - - Generally speaking, every new kernel both adds features and introduces new bugs. - These consequences are the basic properties of upstream kernel development and are - managed by the Yocto Project team's kernel strategy. - It is the Yocto Project team's policy to not back-port minor features to the released kernel. - They only consider back-porting significant technological jumps - and, that is done - after a complete gap analysis. - The reason for this policy is that back-porting any small to medium sized change - from an evolving kernel can easily create mismatches, incompatibilities and very - subtle errors. - - - These policies result in both a stable and a cutting - edge kernel that mixes forward ports of existing features and significant and critical - new functionality. - Forward porting functionality in the kernels available through the Yocto Project kernel - can be thought of as a "micro uprev." - The many “micro uprevs” produce a kernel version with a mix of - important new mainline, non-mainline, BSP developments and feature integrations. - This kernel gives insight into new features and allows focused - amounts of testing to be done on the kernel, which prevents - surprises when selecting the next major uprev. - The quality of these cutting edge kernels is evolving and the kernels are used in leading edge - feature and BSP development. - -
+
+ Modifying an Existing Recipe -
- Kernel Architecture - This section describes the architecture of the kernels available through the - Yocto Project and provides information - on the mechanisms used to achieve that architecture. + In many cases, you can customize an existing linux-yocto recipe to meet the +needs of your project. Each release of the Yocto Project provides a few Linux +kernel recipes to choose from. To get started, prepare a layer and a bbappend +file corresponding to the recipe you wish to modify. + +See [New example in Dev Manual] for instructions to create a minimal layer. + +The bbappend will typical be located at the following location relative to the +layer (if modifying the linux-yocto_3.4.bb recipe): + + recipes-kernel/linux/linux-yocto_3.4.bbappend + +And should contain the following text initially: + + FILESEXTRAPATHS := "${THISDIR}/${PN}" + +The ${PN} will expand to "linux-yocto" in this example. Any new files added to +modify the recipe should then be added to the following path within the layer: + + recipes-kernel/linux/linux-yocto/ + +NOTE: If you are working on a new machine BSP, be sure to refer to the Yocto +Project Board Support Package Developer's Guide. + -
- Overview +
+ Applying Patches + - As mentioned earlier, a key goal of the Yocto Project is to present the - developer with - a kernel that has a clear and continuous history that is visible to the user. - The architecture and mechanisms used achieve that goal in a manner similar to the - upstream kernel.org. - - - You can think of a Yocto Project kernel as consisting of a baseline Linux kernel with - added features logically structured on top of the baseline. - The features are tagged and organized by way of a branching strategy implemented by the - source code manager (SCM) Git. - For information on Git as applied to the Yocto Project, see the - "Git" section in the - Yocto Project Development Manual. - - - The result is that the user has the ability to see the added features and - the commits that make up those features. - In addition to being able to see added features, the user can also view the history of what - made up the baseline kernel. - - - The following illustration shows the conceptual Yocto Project kernel. - - - - - - In the illustration, the "Kernel.org Branch Point" - marks the specific spot (or release) from - which the Yocto Project kernel is created. - From this point "up" in the tree, features and differences are organized and tagged. - - - The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel - type and BSP that is organized further up the tree. - Placing these common features in the - tree this way means features don't have to be duplicated along individual branches of the - structure. - - - From the Yocto Project Baseline Kernel, branch points represent specific functionality - for individual BSPs as well as real-time kernels. - The illustration represents this through three BSP-specific branches and a real-time - kernel branch. - Each branch represents some unique functionality for the BSP or a real-time kernel. - - - In this example structure, the real-time kernel branch has common features for all - real-time kernels and contains - more branches for individual BSP-specific real-time kernels. - The illustration shows three branches as an example. - Each branch points the way to specific, unique features for a respective real-time - kernel as they apply to a given BSP. - - - The resulting tree structure presents a clear path of markers (or branches) to the - developer that, for all practical purposes, is the kernel needed for any given set - of requirements. + If you have a patch, or a small series of patches, to apply to the Linux kernel +source, you can do so just as you would with any other recipe. You first copy +the patches to the path added to FILESEXTRAPATHS in the bbappend file as +described in 2.2 and then reference them in the SRC_URI. + +For example, you can apply a three patch series by adding the following lines to +your linux-yocto bbappend file in your layer: + + SRC_URI += "file://0001-first-change.patch" + SRC_URI += "file://0002-first-change.patch" + SRC_URI += "file://0003-first-change.patch" + +At the next build, bitbake will detect the change in the recipe and fetch and +apply the patches before rebuilding the Linux kernel.
-
- Branching Strategy and Workflow - - The Yocto Project team creates kernel branches at points where functionality is - no longer shared and thus, needs to be isolated. - For example, board-specific incompatibilities would require different functionality - and would require a branch to separate the features. - Likewise, for specific kernel features, the same branching strategy is used. - - - This branching strategy results in a tree that has features organized to be specific - for particular functionality, single kernel types, or a subset of kernel types. - This strategy also results in not having to store the same feature twice - internally in the tree. - Rather, the kernel team stores the unique differences required to apply the - feature onto the kernel type in question. - - The Yocto Project team strives to place features in the tree such that they can be - shared by all boards and kernel types where possible. - However, during development cycles or when large features are merged, - the team cannot always follow this practice. - In those cases, the team uses isolated branches to merge features. - - - - BSP-specific code additions are handled in a similar manner to kernel-specific additions. - Some BSPs only make sense given certain kernel types. - So, for these types, the team creates branches off the end of that kernel type for all - of the BSPs that are supported on that kernel type. - From the perspective of the tools that create the BSP branch, the BSP is really no - different than a feature. - Consequently, the same branching strategy applies to BSPs as it does to features. - So again, rather than store the BSP twice, the team only stores the unique - differences for the BSP across the supported multiple kernels. - - - While this strategy can result in a tree with a significant number of branches, it is - important to realize that from the developer's point of view, there is a linear - path that travels from the baseline kernel.org, through a select - group of features and ends with their BSP-specific commits. - In other words, the divisions of the kernel are transparent and are not relevant - to the developer on a day-to-day basis. - From the developer's perspective, this path is the "master" branch. - The developer does not need to be aware of the existence of any other branches at all. - Of course, there is value in the existence of these branches - in the tree, should a person decide to explore them. - For example, a comparison between two BSPs at either the commit level or at the line-by-line - code diff level is now a trivial operation. - - - Working with the kernel as a structured tree follows recognized community best practices. - In particular, the kernel as shipped with the product, should be - considered an "upstream source" and viewed as a series of - historical and documented modifications (commits). - These modifications represent the development and stabilization done - by the Yocto Project kernel development team. - - - Because commits only change at significant release points in the product life cycle, - developers can work on a branch created - from the last relevant commit in the shipped Yocto Project kernel. - As mentioned previously, the structure is transparent to the developer - because the kernel tree is left in this state after cloning and building the kernel. - -
+
+ Changing the Configuration -
- Source Code Manager - Git - The Source Code Manager (SCM) is Git. - This SCM is the obvious mechanism for meeting the previously mentioned goals. - Not only is it the SCM for kernel.org but, - Git continues to grow in popularity and supports many different work flows, - front-ends and management techniques. - - - You can find documentation on Git at . - You can also get an introduction to Git as it applies to the Yocto Project in the - "Git" - section in the Yocto Project Development Manual. - These referenced sections overview Git and describe a minimal set of - commands that allows you to be functional using Git. - - You can use as much, or as little, of what Git has to offer to accomplish what - you need for your project. - You do not have to be a "Git Master" in order to use it with the Yocto Project. - + Making wholesale or incremental changes to the Linux kernel config can be made +by including a defconfig or configuration fragments in the SRC_URI. + +If you have a complete Linux kernel .config file you want to use, copy it as +"defconfig" to the ${FILES} directory and add the following line to your +linux-yocto bbappend file in your layer: + + SRC_URI += "file://defconfig" + +Generally speaking, the preferred approach is to determine the incremental +change you want to make and add that as a fragment. For example, if you wanted +to add support for a basic serial console, create a file named "8250.cfg" in the +${FILES} directory with the following content (without indentation): + + CONFIG_SERIAL_8250=y + CONFIG_SERIAL_8250_CONSOLE=y + CONFIG_SERIAL_8250_PCI=y + CONFIG_SERIAL_8250_NR_UARTS=4 + CONFIG_SERIAL_8250_RUNTIME_UARTS=4 + CONFIG_SERIAL_CORE=y + CONFIG_SERIAL_CORE_CONSOLE=y + +Then include this configuration fragment in the SRC_URI: + + SRC_URI += "file://8250.cfg" + +At the next build, bitbake will detect the change in the recipe and fetch and +apply the new configuration before rebuilding the Linux kernel.
-
- Kernel Configuration - - Kernel configuration, along with kernel features, defines how a kernel - image is built for the Yocto Project. - Through configuration settings, you can customize a Yocto Project kernel to be - specific to particular hardware. - For example, you can specify sound support or networking support. - This section describes basic concepts behind Kernel configuration within the - Yocto Project and references you to other areas for specific configuration - applications. - +
+ Iterative Development - Conceptually, configuration of a Yocto Project kernel occurs similarly to that needed for any - Linux kernel. - The build process for a Yocto Project kernel uses a .config file, which - is created through the Linux Kernel Configuration (LKC) tool. - You can directly set various configurations in the - .config file by using the menuconfig - tool as built by BitBake. - You can also define configurations in the file by using configuration fragments. - - It is not recommended that you edit the .config file directly. - - Here are some brief descriptions of the ways you can affect the - .config file: - - The menuconfig Tool: - One of many front-ends that allows you to define kernel configurations. - Some others are make config, - make nconfig, and make gconfig. - In the Yocto Project environment, you must use BitBake to build the - menuconfig tool before you can use it to define - configurations: - - $ bitbake linux-yocto -c menuconfig - - After the tool is built, you can interact with it normally. - You can see how menuconfig is used to change a simple - kernel configuration in the - "Configuring the Kernel" - section of the Yocto Project Development Manual. - For general information on menuconfig, see - . - - Configuration Fragments: A file with a - list of kernel options just as they would appear syntactically in the - .config file. - Configuration fragments are typically logical groupings and are assembled - by the OpenEmbedded build system to produce input used by the LKC - that ultimately generates the .config file. - The - KERNEL_FEATURES - variable can be used to list configuration fragments. - For further discussion on applying configuration fragments, see the - "Linux Kernel Configuration" - section in the Yocto Project Board Support Package (BSP) Guide. - - + If you do not have existing patches or configuration files, you can easily +generate them from within the bitbake build environment, as will be described +below. As you do, running previously completed bitbake tasks will cause bitbake +to invalidate the tasks that follow them in the build sequence, causing them to +rebuild at the next invocation of the build. Throughout this section, be sure to +substitute "linux-yocto" with the name of the Linux kernel recipe you are +working with. + + +
+ Generating Configuration Files + + + You can manipulate the config used to build a linux-yocto recipe with the +"menuconfig" command. + + $ bitbake linux-yocto -c menuconfig + +This will start the Linux kernel configuration tool, allowing you to prepare a +new .config for the build. When you exit, be sure to save the changes when +prompted. The resulting .config file will be located in the ${WORKDIR} under +the linux-${MACHINE}-${KTYPE}-build directory. You can use this in its entirety +as the defconfig file described in 2.2.2. + +Better still, would be to use the "menuconfig" command and take the difference +of the new .config file with the previous one to generate a configuration +fragment. To do this, be sure to complete a build at least through the kernel +configuration task: + + $ bitbake linux-yocto -c kernel_configme -f + +Then make a copy of the .config file, calling it "config.orig", for example. Run +the "menuconfig" command as described above. Finally, prepare a configuration +fragment from the difference between the files. Ultimately you want a list of +Linux kernel CONFIG_ assignments, and not something in diff format. Something +like the following will do that automatically (but plan on reviewing the output +as you can usually remove some of the defaults): + + $ diff -Nurp config.orig .config | sed -n "s/^\+//p" > frag.cfg + +You can use the output as a configuration fragment described in 2.2.2. This +method can also be used to define a BSP configuration fragment (See 3.3.5). + +The Yocto Project kernel tools provide some configuration validation tools which +will warn when a configuration you requested does not appear in the final +config, or when you override a policy configuration in a hardware configuration +fragment. You can run these tools with the following command: + + $ bitbake linux-yocto -c kernel_configcheck -f + + ... + + NOTE: validating kernel configuration + This BSP sets 3 invalid/obsolete kernel options. + These config options are not offered anywhere within this kernel. + The full list can be found in your kernel src dir at: + meta/cfg/standard/mybsp/invalid.cfg + + This BSP sets 21 kernel options that are possibly non-hardware related. + The full list can be found in your kernel src dir at: + meta/cfg/standard/mybsp/specified_non_hdw.cfg + + WARNING: There were 2 hardware options requested that do not + have a corresponding value present in the final ".config" file. + This probably means you aren't getting the config you wanted. + The full list can be found in your kernel src dir at: + meta/cfg/standard/mybsp/mismatch.cfg + +The various problems that you can encounter are described in the output along +with where to find the offending configuration items. You can use these logs to +adjust your configuration files and repeat the "kernel_configme" and +"kernel_configcheck" commands until no warnings are produced. + +
+ +
+ Modifying Source Code + + + You can experiment with source code changes and create a simple patch without +leaving the bitbake environment. To get started, be sure to complete a build at +least through the kernel configuration task: + + $ bitbake linux-yocto -c kernel_configme -f + +This step will ensure you have the sources prepared and the configuration +completed. You will find the sources in the ${WORKDIR}/linux directory. + +You can edit the sources as you would any other Linux source tree, but keep in +mind that your changes will be lost if you trigger the fetch task for the +recipe. Avoid this by not issuing the "cleanall" or "cleansstate", or forcing +the "fetch" command. Also be sure not to modify the recipe itself while working +with temporary changes or bitbake may run the fetch command (depending on the +changes to the recipe). + +To test your temporary changes, instruct bitbake to run the compile again. The +-f option forces the command to run again even though bitbake may think it has +already done so: + + $ bitbake linux-yocto -c compile -f + +If the compile fails, you can update the sources and repeat the compile +command. Once it compiles successfully, you can inspect and test the resulting +build (kernel, modules, etc.) from the build directory at +${WORKDIR}/linux-${MACHINE}-${KTYPE}-build. Alternatively, you can run the +deploy command to place the kernel image in the tmp/deploy/images directory: + + $ bitbake linux-yocto -c deploy + +And of course, you can run through all the remaining installation and packaging +steps by issuing: + + $ bitbake linux-yocto + +For rapid iterative development, the edit-compile-repeat loop is preferable to +rebuilding the entire recipe as the installation and packaging tasks are very +time consuming. + +Once you are happy with your modifications, you can make these permanent by +generating patches and applying them to the SRC_URI as described in section +2.2.1 Applying Patches. If you are not familiar with generating patches, refer +to the Yocto Project Development Manual, section 5.7.3 Creating the Patch. + +
+
+ +
+ Working With Your Own Sources + + + If you find yourself unable to work with one of the Linux kernel versions +supported by existing linux-yocto recipes, you can still make use of the Yocto +Project Linux kernel tooling while working with your own sources. You will not +be able to leverage the existing meta-data and stabilization work of the +linux-yocto sources, but you will be able to manage your own meta-data in the +same format as the linux-yocto sources which will facilitate converging with +linux-yocto on a future mutually-supported kernel version. + +The linux-yocto-custom recipe, located in the poky repository at: + + meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb + +is provided as an example recipe which uses kernel.org sources and the Yocto +Project Linux kernel tools for managing meta-data. To get started, copy this +recipe to your layer and provide it with a meaningful name, such as +linux-yocto-myproject_3.5.bb, where 3.5 is the base version of the Linux kernel +you will be working with. In the same directory, create a matching directory, +e.g. linux-yocto-myproject to store your patches and configuration files. + +Edit the following variables in the recipe as appropriate for your project: + + o SRC_URI + o LINUX_VERSION + o LINUX_VERSION_EXTENSION + o SRCREV + o PR + o PV + o COMPATIBLE_MACHINE + +The SRC_URI should be a git repository, using one of the supported git fetcher +protocols (file, git, http, etc.). The skeleton recipe provides an example +SRC_URI as a syntax reference. + +Set LINUX_VERSION to the Linux kernel version you are using, such as "3.6.3". + +LINUX_VERSION_EXTENSION is used to define the Linux kernel CONFIG_LOCALVERSION +which will be compiled in to the resulting kernel and visible via the uname +command. + +Set SRCREV to the commit ID you wish to build from. + +Treat the PR as you would the PR of any other recipe. Increment it to indicate +to the build system that the recipe has changed. + +The default PV assignment is typically adequate. It combines the LINUX_VERSION +with the SCM revision (from the SRCPV variable) and results in a string +something like: + +"3.4.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2" + +While lengthy, this extra verbosity helps ensure you are building from the exact +sources you intend. + +Finally, the default COMPATIBLE_MACHINE assignment for linux-yocto-custom is set +to a regular expression matching only the empty string, "(^$)". This will +trigger an explicit build failure. You must change it to match a list of the +machines supported by your new recipe, such as "(qemux86|qemux86-64)" + +With that in place, you can continue to customize this recipe as you would the +existing linux-yocto recipes. See Section 2.2 Modifying an Existing Recipe for +details.
-
- Kernel Tools +
+ Incorporating Out-of-Tree Modules + - Since most standard workflows involve moving forward with an existing tree by - continuing to add and alter the underlying baseline, the tools that manage - the Yocto Project's kernel construction are largely hidden from the developer to - present a simplified view of the kernel for ease of use. - - - Fundamentally, the kernel tools that manage and construct the - Yocto Project kernel accomplish the following: - - Group patches into named, reusable features. - Allow top-down control of included features. - Bind kernel configurations to kernel patches and features. - Present a seamless Git repository that blends Yocto Project value - with the kernel.org history and development. - + While it is always preferable to work with sources integrated into the Linux +kernel sources, if you have need of an external kernel module, the hello-mod +recipe is available as a template to create your own out-of-tree Linux kernel +module recipe. It is available in the poky repository at: + + meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb + +To get started, copy this recipe to your layer and provide it with a meaningful name, such as +mymodule_1.0.bb. In the same directory, create a directory named "files" where +you can store any source files, patches, or other files necessary for building +the module which do not come with the sources. Finally, update the recipe as +appropriate for the module. Typically you will need to set the following +variables: + + o DESCRIPTION + o LICENSE* + o SRC_URI + o PV + +Depending on the build system used by the module sources, you may need to make +adjustments. For example, a typical module Makefile will look much like that +provided with hello-mod: + + obj-m := hello.o + + SRC := $(shell pwd) + + all: + $(MAKE) -C $(KERNEL_SRC) M=$(SRC) + + modules_install: + $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install + ... + +The important point to note here is the KERNEL_SRC variable. The module bbclass +class sets this, as well as KERNEL_PATH, to ${STAGING_KERNEL_DIR} with the +necessary Linux kernel build information to build modules. If your module +Makefile uses a different variable, you may want to override the do_compile() +step, or create a patch to the Makefile to work with the more typical KERNEL_SRC +or KERNEL_PATH variables. + +After you have prepared the recipe, you will likely want to include the module +in your images. To do this, see the documentation for the following variables in +the Yocto Project Reference Manual and set one of them as appropriate in your +machine config file: + + MACHINE_ESSENTIAL_EXTRA_RDEPENDS + MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS + MACHINE_EXTRA_RDEPENDS + MACHINE_EXTRA_RRECOMMENDS + +As modules are often not required for boot and may be excluded from certain +build configurations, the following allows for the most flexibility: + + MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule" + +Where the value is derived by appending the module filename without the .ko +extension to the string "kernel-module-". + +As it is an RRECOMMENDS (and not an RDEPENDS) variable, the build will not fail +if this module is not available to include in the image.
diff --git a/documentation/kernel-dev/kernel-dev.xml b/documentation/kernel-dev/kernel-dev.xml index ab8f45366c..1bbd0feb45 100644 --- a/documentation/kernel-dev/kernel-dev.xml +++ b/documentation/kernel-dev/kernel-dev.xml @@ -59,9 +59,9 @@ -