1
0
mirror of https://git.yoctoproject.org/poky synced 2026-05-31 12:49:46 +00:00

documentation: poky-ref-manual - Edits to feature backfill

Final edits (I think) to this section from Paul Eggleton.

(From yocto-docs rev: 95fd830ffb668109631205df4538454ccf023b20)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2012-10-19 06:28:12 -07:00
committed by Richard Purdie
parent c6ce06b172
commit 014f91cb3f
+24 -27
View File
@@ -178,38 +178,35 @@
<title>Feature Backfilling</title> <title>Feature Backfilling</title>
<para> <para>
Sometimes it is necessary to control functionality enabled by features Sometimes it is necessary in the OpenEmbedded build system to extend
that are listed with
<link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link> <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
and <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>. or <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
For example, some functionality exists that is enabled to control functionality that was previously enabled and not able
by default for all configurations. to be disabled.
For these cases, the metadata, as shipped with the Yocto Project, ensures For these cases, we need to add an
the feature is "backfilled" into all the specific distro additional feature item to appear in one of these variables,
and machine configurations. but we do not want to force developers who have existing values
You can see how this is done by finding the of the variables in their configuration to add the new feature
in order to retain the same overall level of functionality.
Thus, the OpenEmbedded build system has a mechanism to
automatically "backfill" these added features into existing
distro or machine configurations.
You can see the list of features for which this is done by
finding the
<link linkend='var-DISTRO_FEATURES_BACKFILL'><filename>DISTRO_FEATURES_BACKFILL</filename></link> <link linkend='var-DISTRO_FEATURES_BACKFILL'><filename>DISTRO_FEATURES_BACKFILL</filename></link>
and <link linkend='var-MACHINE_FEATURES_BACKFILL'><filename>MACHINE_FEATURES_BACKFILL</filename></link> and <link linkend='var-MACHINE_FEATURES_BACKFILL'><filename>MACHINE_FEATURES_BACKFILL</filename></link>
variables in the <filename>meta/conf/bitbake.conf</filename> file. variables in the <filename>meta/conf/bitbake.conf</filename> file.
</para> </para>
<para> <para>
Because certain functionality is enabled across all configurations as Because such features are backfilled by default into all
described in the previous paragraph, it also becomes necessary configurations as described in the previous paragraph, developers
to give the developer the ability to disable (remove) a feature who wish to disable the new features need to be able to selectively
from a particular configuration. prevent the backfilling from occurring.
For example, suppose you have a machine feature that needs to be They can do this by adding the undesired feature or features to the
disabled but the metadata has backfilled it across all configurations as enabled. <link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link>
You need to be able to remove the feature from your configuration's or <link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link>
<filename>MACHINE_FEATURES</filename> variables for distro features and machine features respectively.
without disturbing existing configurations that still
might need the functionality?
</para>
<para>
Feature backfilling allows you to selectively prevent a feature from
being backfilled to <filename>MACHINE_FEATURES</filename>,
<filename>DISTRO_FEATURES</filename>, or both.
</para> </para>
<para> <para>
@@ -226,7 +223,7 @@
You can disable the feature without affecting You can disable the feature without affecting
other existing distro configurations that need PulseAudio support other existing distro configurations that need PulseAudio support
by adding "pulseaudio" to by adding "pulseaudio" to
<link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link> DISTRO_FEATURES_BACKFILL_CONSIDERED
in your distro's <filename>.conf</filename> file. in your distro's <filename>.conf</filename> file.
Adding the feature to this variable when it also Adding the feature to this variable when it also
exists in the <filename>DISTRO_FEATURES_BACKFILL</filename> exists in the <filename>DISTRO_FEATURES_BACKFILL</filename>
@@ -243,7 +240,7 @@
You can disable RTC support for your device without You can disable RTC support for your device without
affecting other machines that need RTC support affecting other machines that need RTC support
by adding the feature to your machine's by adding the feature to your machine's
<link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link> MACHINE_FEATURES_BACKFILL_CONSIDERED
list in the machine's <filename>.conf</filename> file. list in the machine's <filename>.conf</filename> file.
Adding the feature to this variable when it also Adding the feature to this variable when it also
exists in the <filename>MACHINE_FEATURES_BACKFILL</filename> exists in the <filename>MACHINE_FEATURES_BACKFILL</filename>