manuals: inclusive language updates

Changes identified by OE core's
scripts/contrib/convert-variable-renames.py script

Original variable names are kept in old migration notes,
but references to the new ones are provided.

(From yocto-docs rev: 1a35380ca80509fee036018a2bbb22ba9b44d47a)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/bsp-guide/bsp.rst

@@ -1113,7 +1113,7 @@ list describes them in order of preference:
 #. *Use the LICENSE_FLAGS Variable to Define the Recipes that Have Commercial or
    Other Types of Specially-Licensed Packages:* For each of those recipes, you can
    specify a matching license string in a ``local.conf`` variable named
-   :term:`LICENSE_FLAGS_WHITELIST`.
+   :term:`LICENSE_FLAGS_ACCEPTED`.
    Specifying the matching license string signifies that you agree to
    the license. Thus, the build system can build the corresponding
    recipe and include the component in the image. See the
@@ -1122,15 +1122,15 @@ list describes them in order of preference:
    how to use these variables.
 
    If you build as you normally would, without specifying any recipes in
-   the :term:`LICENSE_FLAGS_WHITELIST` variable, the build stops and provides
+   the :term:`LICENSE_FLAGS_ACCEPTED` variable, the build stops and provides
    you with the list of recipes that you have tried to include in the image
-   that need entries in the :term:`LICENSE_FLAGS_WHITELIST` variable. Once you
+   that need entries in the :term:`LICENSE_FLAGS_ACCEPTED` variable. Once you
    enter the appropriate license flags into it, restart the build to continue
    where it left off. During the build, the prompt will not appear again since
    you have satisfied the requirement.
 
    Once the appropriate license flags are on the white list in the
-   :term:`LICENSE_FLAGS_WHITELIST` variable, you can build the encumbered
+   :term:`LICENSE_FLAGS_ACCEPTED` variable, you can build the encumbered
    image with no change at all to the normal build process.
 
 #. *Get a Pre-Built Version of the BSP:* You can get this type of BSP by
@@ -1143,7 +1143,7 @@ list describes them in order of preference:
    click-through license agreements presented by the website. If you
    want to build the image yourself using the recipes contained within
    the BSP tarball, you will still need to create an appropriate
-   :term:`LICENSE_FLAGS_WHITELIST` to match the encumbered recipes in the
+   :term:`LICENSE_FLAGS_ACCEPTED` to match the encumbered recipes in the
    BSP.
 
 .. note::

documentation/dev-manual/common-tasks.rst

@@ -11037,17 +11037,17 @@ name and version (after variable expansion)::
 In order for a component restricted by a
 :term:`LICENSE_FLAGS` definition to be enabled and included in an image, it
 needs to have a matching entry in the global
-:term:`LICENSE_FLAGS_WHITELIST`
+:term:`LICENSE_FLAGS_ACCEPTED`
 variable, which is a variable typically defined in your ``local.conf``
 file. For example, to enable the
 ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you
 could add either the string "commercial_gst-plugins-ugly" or the more
-general string "commercial" to :term:`LICENSE_FLAGS_WHITELIST`. See the
+general string "commercial" to :term:`LICENSE_FLAGS_ACCEPTED`. See the
 ":ref:`dev-manual/common-tasks:license flag matching`" section for a full
 explanation of how :term:`LICENSE_FLAGS` matching works. Here is the
 example::
 
-   LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
+   LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly"
 
 Likewise, to additionally enable the package built from the recipe
 containing ``LICENSE_FLAGS = "license_${PN}_${PV}"``, and assuming that
@@ -11055,7 +11055,7 @@ the actual recipe name was ``emgd_1.10.bb``, the following string would
 enable that package as well as the original ``gst-plugins-ugly``
 package::
 
-   LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
+   LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly license_emgd_1.10"
 
 As a convenience, you do not need to specify the
 complete license string for every package. You can use
@@ -11068,7 +11068,7 @@ previously mentioned as well as any other packages that have licenses
 starting with "commercial" or "license".
 ::
 
-   LICENSE_FLAGS_WHITELIST = "commercial license"
+   LICENSE_FLAGS_ACCEPTED = "commercial license"
 
 License Flag Matching
 ~~~~~~~~~~~~~~~~~~~~~
@@ -11076,7 +11076,7 @@ License Flag Matching
 License flag matching allows you to control what recipes the
 OpenEmbedded build system includes in the build. Fundamentally, the
 build system attempts to match :term:`LICENSE_FLAGS` strings found in
-recipes against strings found in :term:`LICENSE_FLAGS_WHITELIST`.
+recipes against strings found in :term:`LICENSE_FLAGS_ACCEPTED`.
 A match causes the build system to include a recipe in the
 build, while failure to find a match causes the build system to exclude
 a recipe.
@@ -11085,19 +11085,19 @@ In general, license flag matching is simple. However, understanding some
 concepts will help you correctly and effectively use matching.
 
 Before a flag defined by a particular recipe is tested against the
-entries of :term:`LICENSE_FLAGS_WHITELIST`, the expanded
+entries of :term:`LICENSE_FLAGS_ACCEPTED`, the expanded
 string ``_${PN}`` is appended to the flag. This expansion makes each
 :term:`LICENSE_FLAGS` value recipe-specific. After expansion, the
 string is then matched against the entries. Thus, specifying
 ``LICENSE_FLAGS = "commercial"`` in recipe "foo", for example, results
 in the string ``"commercial_foo"``. And, to create a match, that string
-must appear among the entries of :term:`LICENSE_FLAGS_WHITELIST`.
+must appear among the entries of :term:`LICENSE_FLAGS_ACCEPTED`.
 
 Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the
-:term:`LICENSE_FLAGS_WHITELIST` variable allows you a lot of flexibility for
+:term:`LICENSE_FLAGS_ACCEPTED` variable allows you a lot of flexibility for
 including or excluding recipes based on licensing. For example, you can
 broaden the matching capabilities by using license flags string subsets
-in :term:`LICENSE_FLAGS_WHITELIST`.
+in :term:`LICENSE_FLAGS_ACCEPTED`.
 
 .. note::
 
@@ -11106,7 +11106,7 @@ in :term:`LICENSE_FLAGS_WHITELIST`.
    ``usethispart_1.3``, ``usethispart_1.4``, and so forth).
 
 For example, simply specifying the string "commercial" in the
-:term:`LICENSE_FLAGS_WHITELIST` variable matches any expanded
+:term:`LICENSE_FLAGS_ACCEPTED` variable matches any expanded
 :term:`LICENSE_FLAGS` definition that starts with the string
 "commercial" such as "commercial_foo" and "commercial_bar", which
 are the strings the build system automatically generates for
@@ -11124,24 +11124,24 @@ This scheme works even if the :term:`LICENSE_FLAGS` string already has
 ``_${PN}`` appended. For example, the build system turns the license
 flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match
 both the general "commercial" and the specific "commercial_1.2_foo"
-strings found in the :term:`LICENSE_FLAGS_WHITELIST` variable, as expected.
+strings found in the :term:`LICENSE_FLAGS_ACCEPTED` variable, as expected.
 
 Here are some other scenarios:
 
 -  You can specify a versioned string in the recipe such as
    "commercial_foo_1.2" in a "foo" recipe. The build system expands this
    string to "commercial_foo_1.2_foo". Combine this license flag with a
-   :term:`LICENSE_FLAGS_WHITELIST` variable that has the string
+   :term:`LICENSE_FLAGS_ACCEPTED` variable that has the string
    "commercial" and you match the flag along with any other flag that
    starts with the string "commercial".
 
 -  Under the same circumstances, you can add "commercial_foo" in the
-   :term:`LICENSE_FLAGS_WHITELIST` variable and the build system not only
+   :term:`LICENSE_FLAGS_ACCEPTED` variable and the build system not only
    matches "commercial_foo_1.2" but also matches any license flag with
    the string "commercial_foo", regardless of the version.
 
 -  You can be very specific and use both the package and version parts
-   in the :term:`LICENSE_FLAGS_WHITELIST` list (e.g.
+   in the :term:`LICENSE_FLAGS_ACCEPTED` list (e.g.
    "commercial_foo_1.2") to specifically match a versioned recipe.
 
 Other Variables Related to Commercial Licenses
@@ -11163,20 +11163,20 @@ file::
        gst-plugins-ugly-mpegaudioparse"
    COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
-   LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
+   LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
 
 
 Of course, you could also create a matching list for those
 components using the more general "commercial" in the
-:term:`LICENSE_FLAGS_WHITELIST` variable, but that would also enable all
+:term:`LICENSE_FLAGS_ACCEPTED` variable, but that would also enable all
 the other packages with :term:`LICENSE_FLAGS`
 containing "commercial", which you may or may not want::
 
-   LICENSE_FLAGS_WHITELIST = "commercial"
+   LICENSE_FLAGS_ACCEPTED = "commercial"
 
 Specifying audio and video plugins as part of the
 ``COMMERCIAL_AUDIO_PLUGINS`` and ``COMMERCIAL_VIDEO_PLUGINS`` statements
-(along with the enabling :term:`LICENSE_FLAGS_WHITELIST`) includes the
+(along with the enabling :term:`LICENSE_FLAGS_ACCEPTED`) includes the
 plugins or components into built images, thus adding support for media
 formats or components.
 
@@ -11540,7 +11540,7 @@ The NIST database knows which versions are vulnerable and which ones
 are not.
 
 Last but not least, you can choose to ignore vulnerabilities through
-the :term:`CVE_CHECK_PN_WHITELIST` and :term:`CVE_CHECK_WHITELIST`
+the :term:`CVE_CHECK_SKIP_RECIPE` and :term:`CVE_CHECK_IGNORE`
 variables.
 
 Implementation details
@@ -11559,9 +11559,9 @@ Then, the code looks up all the CVE IDs in the NIST database for all the
 products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
 
  - If the package name (:term:`PN`) is part of
-   :term:`CVE_CHECK_PN_WHITELIST`, it is considered as patched.
+   :term:`CVE_CHECK_SKIP_RECIPE`, it is considered as patched.
 
- - If the CVE ID is part of :term:`CVE_CHECK_WHITELIST`, it is
+ - If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is
    considered as patched too.
 
  - If the CVE ID is part of the patched CVE for the recipe, it is

documentation/migration-guides/migration-2.2.rst

@@ -26,8 +26,8 @@ Staging Directories in Sysroot Has Been Simplified
 
 The way directories are staged in sysroot has been simplified and
 introduces the new :term:`SYSROOT_DIRS`,
-:term:`SYSROOT_DIRS_NATIVE`, and
-:term:`SYSROOT_DIRS_BLACKLIST`. See the
+:term:`SYSROOT_DIRS_NATIVE`, and ``SYSROOT_DIRS_BLACKLIST``
+(replaced by :term:`SYSROOT_DIRS_IGNORE` in version 3.5). See the
 :oe_lists:`v2 patch series on the OE-Core Mailing List
 </pipermail/openembedded-core/2016-May/121365.html>`
 for additional information.

documentation/migration-guides/migration-3.0.rst

@@ -148,7 +148,7 @@ XML feeds that ``cve-check-tool`` was using, supports CVSSv3 scoring,
 and makes other improvements.
 
 Additionally, the ``CVE_CHECK_CVE_WHITELIST`` variable has been replaced
-by ``CVE_CHECK_WHITELIST``.
+by ``CVE_CHECK_WHITELIST`` (replaced by :term:`CVE_CHECK_IGNORE` in version 3.5).
 
 .. _migration-3.0-bitbake-changes:
 

documentation/migration-guides/migration-3.4.rst

@@ -255,7 +255,8 @@ Miscellaneous
 
 - The previously deprecated ``COMPRESS_CMD`` and
   ``CVE_CHECK_CVE_WHITELIST`` variables have been removed. Use
-  ``CONVERSION_CMD`` and :term:`CVE_CHECK_WHITELIST` respectively
+  ``CONVERSION_CMD`` and ``CVE_CHECK_WHITELIST`` (replaced by
+  :term:`CVE_CHECK_IGNORE` in version 3.5) respectively
   instead.
 
 - The obsolete ``oe_machinstall`` function previously provided in the

documentation/overview-manual/concepts.rst

@@ -1372,15 +1372,15 @@ associated with an extensible SDK:
    Specifies whether or not the toolchain is included when building the
    extensible SDK.
 
--  :term:`SDK_LOCAL_CONF_WHITELIST`:
+-  :term:`ESDK_LOCALCONF_ALLOW`:
    A list of variables allowed through from the build system
    configuration into the extensible SDK configuration.
 
--  :term:`SDK_LOCAL_CONF_BLACKLIST`:
+-  :term:`ESDK_LOCALCONF_REMOVE`:
    A list of variables not allowed through from the build system
    configuration into the extensible SDK configuration.
 
--  :term:`SDK_INHERIT_BLACKLIST`:
+-  :term:`ESDK_CLASS_INHERIT_DISABLE`:
    A list of classes to remove from the
    :term:`INHERIT` value globally
    within the extensible SDK configuration.
@@ -1722,7 +1722,7 @@ it construct the basehash. The following statement effectively results
 in a list of global variable dependency excludes (i.e. variables never
 included in any checksum)::
 
-   BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \\
+   BB_BASEHASH_IGNORE_VARS ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \\
        SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \\
        USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \\
        PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\

documentation/ref-manual/classes.rst

@@ -828,13 +828,13 @@ provided by the recipe ``icecc-create-env-native.bb``.
 If you do not want the Icecream distributed compile support to apply to
 specific recipes or classes, you can ask them to be ignored by Icecream
 by listing the recipes and classes using the
-:term:`ICECC_USER_PACKAGE_BL` and
-:term:`ICECC_USER_CLASS_BL` variables,
+:term:`ICECC_RECIPE_DISABLE` and
+:term:`ICECC_CLASS_DISABLE` variables,
 respectively, in your ``local.conf`` file. Doing so causes the
 OpenEmbedded build system to handle these compilations locally.
 
 Additionally, you can list recipes using the
-:term:`ICECC_USER_PACKAGE_WL` variable in
+:term:`ICECC_RECIPE_ENABLE` variable in
 your ``local.conf`` file to force ``icecc`` to be enabled for recipes
 using an empty :term:`PARALLEL_MAKE` variable.
 
@@ -2497,7 +2497,7 @@ stages:
    subset of files is controlled by the
    :term:`SYSROOT_DIRS`,
    :term:`SYSROOT_DIRS_NATIVE`, and
-   :term:`SYSROOT_DIRS_BLACKLIST`
+   :term:`SYSROOT_DIRS_IGNORE`
    variables.
 
    .. note::

documentation/ref-manual/variables.rst

@@ -1472,16 +1472,16 @@ system and gives an overview of their function and contents.
          variable only in certain contexts (e.g. when building for kernel
          and kernel module recipes).
 
-   :term:`CVE_CHECK_PN_WHITELIST`
+   :term:`CVE_CHECK_SKIP_RECIPE`
       The list of package names (:term:`PN`) for which
       CVEs (Common Vulnerabilities and Exposures) are ignored.
 
-   :term:`CVE_CHECK_WHITELIST`
+   :term:`CVE_CHECK_IGNORE`
       The list of CVE IDs which are ignored. Here is
       an example from the :oe_layerindex:`Python3 recipe</layerindex/recipe/23823>`::
 
          # This is windows only issue.
-         CVE_CHECK_WHITELIST += "CVE-2020-15523"
+         CVE_CHECK_IGNORE += "CVE-2020-15523"
 
    :term:`CVE_PRODUCT`
       In a recipe, defines the name used to match the recipe name
@@ -2879,7 +2879,7 @@ system and gives an overview of their function and contents.
       this variable, the :ref:`icecc <ref-classes-icecc>` class attempts
       to define it by locating ``icecc`` using ``which``.
 
-   :term:`ICECC_USER_CLASS_BL`
+   :term:`ICECC_CLASS_DISABLE`
       Identifies user classes that you do not want the Icecream distributed
       compile support to consider. This variable is used by the
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
@@ -2889,7 +2889,7 @@ system and gives an overview of their function and contents.
       those classes will not benefit from distributed compilation across
       remote hosts. Instead they will be built locally.
 
-   :term:`ICECC_USER_PACKAGE_BL`
+   :term:`ICECC_RECIPE_DISABLE`
       Identifies user recipes that you do not want the Icecream distributed
       compile support to consider. This variable is used by the
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
@@ -2899,7 +2899,7 @@ system and gives an overview of their function and contents.
       from distributed compilation across remote hosts. Instead they will
       be built locally.
 
-   :term:`ICECC_USER_PACKAGE_WL`
+   :term:`ICECC_RECIPE_ENABLE`
       Identifies user recipes that use an empty
       :term:`PARALLEL_MAKE` variable that you want to
       force remote distributed compilation on using the Icecream
@@ -4375,7 +4375,7 @@ system and gives an overview of their function and contents.
 
    :term:`LICENSE_FLAGS`
       Specifies additional flags for a recipe you must allow through
-      :term:`LICENSE_FLAGS_WHITELIST` in
+      :term:`LICENSE_FLAGS_ACCEPTED` in
       order for the recipe to be built. When providing multiple flags,
       separate them with spaces.
 
@@ -4386,7 +4386,7 @@ system and gives an overview of their function and contents.
       ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
       section in the Yocto Project Development Tasks Manual.
 
-   :term:`LICENSE_FLAGS_WHITELIST`
+   :term:`LICENSE_FLAGS_ACCEPTED`
       Lists license flags that when specified in
       :term:`LICENSE_FLAGS` within a recipe should not
       prevent that recipe from being built.  For more information, see the
@@ -6548,13 +6548,13 @@ system and gives an overview of their function and contents.
       :term:`SDK_EXT_TYPE` is set to "minimal", and defaults to "1" if
       :term:`SDK_EXT_TYPE` is set to "full".
 
-   :term:`SDK_INHERIT_BLACKLIST`
+   :term:`ESDK_CLASS_INHERIT_DISABLE`
       A list of classes to remove from the :term:`INHERIT`
       value globally within the extensible SDK configuration. The
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class sets the
       default value::
 
-         SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
+         ESDK_CLASS_INHERIT_DISABLE ?= "buildhistory icecc"
 
       Some classes are not generally applicable within the extensible SDK
       context. You can use this variable to disable those classes.
@@ -6565,14 +6565,14 @@ system and gives an overview of their function and contents.
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
-   :term:`SDK_LOCAL_CONF_BLACKLIST`
+   :term:`ESDK_LOCALCONF_REMOVE`
       A list of variables not allowed through from the OpenEmbedded build
       system configuration into the extensible SDK configuration. Usually,
       these are variables that are specific to the machine on which the
       build system is running and thus would be potentially problematic
       within the extensible SDK.
 
-      By default, :term:`SDK_LOCAL_CONF_BLACKLIST` is set in the
+      By default, :term:`ESDK_LOCALCONF_REMOVE` is set in the
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class and
       excludes the following variables:
 
@@ -6591,14 +6591,14 @@ system and gives an overview of their function and contents.
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
-   :term:`SDK_LOCAL_CONF_WHITELIST`
+   :term:`ESDK_LOCALCONF_ALLOW`
       A list of variables allowed through from the OpenEmbedded build
       system configuration into the extensible SDK configuration. By
       default, the list of variables is empty and is set in the
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
 
       This list overrides the variables specified using the
-      :term:`SDK_LOCAL_CONF_BLACKLIST` variable as well as
+      :term:`ESDK_LOCALCONF_REMOVE` variable as well as
       other variables automatically added due to the "/" character
       being found at the start of the
       value, which is usually indicative of being a path and thus might not
@@ -7506,14 +7506,14 @@ system and gives an overview of their function and contents.
              /sysroot-only \
              "
 
-   :term:`SYSROOT_DIRS_BLACKLIST`
+   :term:`SYSROOT_DIRS_IGNORE`
       Directories that are not staged into the sysroot by the
       :ref:`ref-tasks-populate_sysroot` task. You
       can use this variable to exclude certain subdirectories of
       directories listed in :term:`SYSROOT_DIRS` from
       staging. By default, the following directories are not staged::
 
-         SYSROOT_DIRS_BLACKLIST = " \
+         SYSROOT_DIRS_IGNORE = " \
              ${mandir} \
              ${docdir} \
              ${infodir} \
@@ -8426,7 +8426,7 @@ system and gives an overview of their function and contents.
       passes and uses "all" for the target during the U-Boot building
       process.
 
-   :term:`UNKNOWN_CONFIGURE_WHITELIST`
+   :term:`UNKNOWN_CONFIGURE_OPT_IGNORE`
       Specifies a list of options that, if reported by the configure script
       as being invalid, should not generate a warning during the
       :ref:`ref-tasks-configure` task. Normally, invalid
@@ -8436,10 +8436,10 @@ system and gives an overview of their function and contents.
       However, there are common options that are passed to all
       configure scripts at a class level, but might not be valid for some
       configure scripts. Therefore warnings about these options are useless.
-      For these cases, the options are added to :term:`UNKNOWN_CONFIGURE_WHITELIST`.
+      For these cases, the options are added to :term:`UNKNOWN_CONFIGURE_OPT_IGNORE`.
 
       The configure arguments check that uses
-      :term:`UNKNOWN_CONFIGURE_WHITELIST` is part of the
+      :term:`UNKNOWN_CONFIGURE_OPT_IGNORE` is part of the
       :ref:`insane <ref-classes-insane>` class and is only enabled if the
       recipe inherits the :ref:`autotools <ref-classes-autotools>` class.
 

documentation/sdk-manual/appendix-customizing.rst

@@ -21,7 +21,7 @@ build system applies them against ``local.conf`` and ``auto.conf``:
    specific to the :term:`Build Host`.
 
 -  Variables listed in
-   :term:`SDK_LOCAL_CONF_BLACKLIST`
+   :term:`ESDK_LOCALCONF_REMOVE`
    are excluded. These variables are not allowed through from the
    OpenEmbedded build system configuration into the extensible SDK
    configuration. Typically, these variables are specific to the machine
@@ -29,19 +29,19 @@ build system applies them against ``local.conf`` and ``auto.conf``:
    of the extensible SDK configuration.
 
    For a list of the variables excluded by default, see the
-   :term:`SDK_LOCAL_CONF_BLACKLIST`
+   :term:`ESDK_LOCALCONF_REMOVE`
    in the glossary of the Yocto Project Reference Manual.
 
 -  Variables listed in
-   :term:`SDK_LOCAL_CONF_WHITELIST`
+   :term:`ESDK_LOCALCONF_ALLOW`
    are included. Including a variable in the value of
-   :term:`SDK_LOCAL_CONF_WHITELIST` overrides either of the previous two
+   :term:`ESDK_LOCALCONF_ALLOW` overrides either of the previous two
    filters. The default value is blank.
 
 -  Classes inherited globally with
    :term:`INHERIT` that are listed in
-   :term:`SDK_INHERIT_BLACKLIST`
-   are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these
+   :term:`ESDK_CLASS_INHERIT_DISABLE`
+   are disabled. Using :term:`ESDK_CLASS_INHERIT_DISABLE` to disable these
    classes is the typical method to disable classes that are problematic
    or unnecessary in the SDK context. The default value disables the
    :ref:`buildhistory <ref-classes-buildhistory>`
@@ -63,13 +63,13 @@ adjustments:
 -  If your SDK configuration inherits additional classes using the
    :term:`INHERIT` variable and you
    do not need or want those classes enabled in the SDK, you can
-   disable them by adding them to the :term:`SDK_INHERIT_BLACKLIST`
+   disable them by adding them to the :term:`ESDK_CLASS_INHERIT_DISABLE`
    variable as described in the previous section.
 
    .. note::
 
       The default value of
-      SDK_INHERIT_BLACKLIST
+      ESDK_CLASS_INHERIT_DISABLE
       is set using the "?=" operator. Consequently, you will need to
       either define the entire list by using the "=" operator, or you
       will need to append a value using either ":append" or the "+="
@@ -92,7 +92,7 @@ adjustments:
 
    -  Disable the tasks if they are added by a class and you do not need
       the functionality the class provides in the extensible SDK. To
-      disable the tasks, add the class to the :term:`SDK_INHERIT_BLACKLIST`
+      disable the tasks, add the class to the :term:`ESDK_CLASS_INHERIT_DISABLE`
       variable as described in the previous section.
 
 -  Generally, you want to have a shared state mirror set up so users of
@@ -277,7 +277,7 @@ source, you need to do a number of things:
       configuration file. You can then pass the variable to the SDK by
       adding the following::
 
-         SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
+         ESDK_LOCALCONF_ALLOW = "SSTATE_MIRRORS"
 
    -  Alternatively, if you just want to set the :term:`SSTATE_MIRRORS`
       variable's value for the SDK alone, create a