kernel-dev: Eliminated a redundant paragraph.
Noticed the exact same paragraph at the beginning of Chapter 3 that also appears in the introductory text for the manual. (From yocto-docs rev: 431cb58ca144bbf5aa49caa7dc2b728c3c92fe66) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
6668012b67
commit
9bf1cde472
|
@ -18,26 +18,6 @@
|
|||
to help you manage the complexity of the configuration and sources
|
||||
used to support multiple BSPs and Linux kernel types.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In particular, the kernel tools allow you to specify only what you
|
||||
must, and nothing more.
|
||||
Where a complete Linux kernel <filename>.config</filename> includes
|
||||
all the automatically selected <filename>CONFIG</filename> options,
|
||||
the configuration fragments only need to contain the highest level
|
||||
visible <filename>CONFIG</filename> options as presented by the Linux
|
||||
kernel <filename>menuconfig</filename> system.
|
||||
This reduces your maintenance effort and allows you
|
||||
to further separate your configuration in ways that make sense for
|
||||
your project.
|
||||
A common split is policy and hardware.
|
||||
For example, all your kernels might support
|
||||
the <filename>proc</filename> and <filename>sys</filename> filesystems,
|
||||
but only specific boards will require sound, USB, or specific drivers.
|
||||
Specifying these individually allows you to aggregate them
|
||||
together as needed, but maintain them in only one place.
|
||||
Similar logic applies to source changes.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='using-kernel-metadata-in-a-recipe'>
|
||||
|
|
Loading…
Reference in New Issue