blob: ae5a0e3b24888afbbf6eea59f669bed58b79ebdd [file] [log] [blame]
Andrew Geissler4873add2020-11-02 18:44:49 -06001.. SPDX-License-Identifier: CC-BY-2.0-UK
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002
3********
4Features
5********
6
7This chapter provides a reference of shipped machine and distro features
8you can include as part of your image, a reference on image features you
9can select, and a reference on feature backfilling.
10
11Features provide a mechanism for working out which packages should be
12included in the generated images. Distributions can select which
13features they want to support through the ``DISTRO_FEATURES`` variable,
14which is set or appended to in a distribution's configuration file such
15as ``poky.conf``, ``poky-tiny.conf``, ``poky-lsb.conf`` and so forth.
16Machine features are set in the ``MACHINE_FEATURES`` variable, which is
17set in the machine configuration file and specifies the hardware
18features for a given machine.
19
20These two variables combine to work out which kernel modules, utilities,
21and other packages to include. A given distribution can support a
22selected subset of features so some machine features might not be
23included if the distribution itself does not support them.
24
25One method you can use to determine which recipes are checking to see if
26a particular feature is contained or not is to ``grep`` through the
27:term:`Metadata` for the feature. Here is an example that
28discovers the recipes whose build is potentially changed based on a
29given feature:
30::
31
32 $ cd poky
33 $ git grep 'contains.*MACHINE_FEATURES.*feature'
34
35.. _ref-features-machine:
36
37Machine Features
38================
39
40The items below are features you can use with
41:term:`MACHINE_FEATURES`. Features do not have a
42one-to-one correspondence to packages, and they can go beyond simply
43controlling the installation of a package or packages. Sometimes a
44feature can influence how certain recipes are built. For example, a
45feature might determine whether a particular configure option is
46specified within the :ref:`ref-tasks-configure` task
47for a particular recipe.
48
49This feature list only represents features as shipped with the Yocto
50Project metadata:
51
52- *acpi:* Hardware has ACPI (x86/x86_64 only)
53
54- *alsa:* Hardware has ALSA audio drivers
55
56- *apm:* Hardware uses APM (or APM emulation)
57
58- *bluetooth:* Hardware has integrated BT
59
60- *efi:* Support for booting through EFI
61
62- *ext2:* Hardware HDD or Microdrive
63
64- *keyboard:* Hardware has a keyboard
65
66- *pcbios:* Support for booting through BIOS
67
68- *pci:* Hardware has a PCI bus
69
70- *pcmcia:* Hardware has PCMCIA or CompactFlash sockets
71
72- *phone:* Mobile phone (voice) support
73
74- *qvga:* Machine has a QVGA (320x240) display
75
76- *rtc:* Machine has a Real-Time Clock
77
78- *screen:* Hardware has a screen
79
80- *serial:* Hardware has serial support (usually RS232)
81
82- *touchscreen:* Hardware has a touchscreen
83
84- *usbgadget:* Hardware is USB gadget device capable
85
86- *usbhost:* Hardware is USB Host capable
87
88- *vfat:* FAT file system support
89
90- *wifi:* Hardware has integrated WiFi
91
92.. _ref-features-distro:
93
94Distro Features
95===============
96
97The items below are features you can use with
98:term:`DISTRO_FEATURES` to enable features across
99your distribution. Features do not have a one-to-one correspondence to
100packages, and they can go beyond simply controlling the installation of
101a package or packages. In most cases, the presence or absence of a
102feature translates to the appropriate option supplied to the configure
103script during the :ref:`ref-tasks-configure` task for
104the recipes that optionally support the feature.
105
106Some distro features are also machine features. These select features
107make sense to be controlled both at the machine and distribution
108configuration level. See the
109:term:`COMBINED_FEATURES` variable for more
110information.
111
112This list only represents features as shipped with the Yocto Project
113metadata:
114
115- *alsa:* Include ALSA support (OSS compatibility kernel modules
116 installed if available).
117
118- *api-documentation:* Enables generation of API documentation during
119 recipe builds. The resulting documentation is added to SDK tarballs
120 when the ``bitbake -c populate_sdk`` command is used. See the
121 ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding api documentation to the standard sdk`"
122 section in the Yocto Project Application Development and the
123 Extensible Software Development Kit (eSDK) manual.
124
125- *bluetooth:* Include bluetooth support (integrated BT only).
126
127- *cramfs:* Include CramFS support.
128
129- *directfb:* Include DirectFB support.
130
131- *ext2:* Include tools for supporting for devices with internal
132 HDD/Microdrive for storing files (instead of Flash only devices).
133
134- *ipsec:* Include IPSec support.
135
136- *ipv6:* Include IPv6 support.
137
138- *keyboard:* Include keyboard support (e.g. keymaps will be loaded
139 during boot).
140
141- *ldconfig:* Include support for ldconfig and ``ld.so.conf`` on the
142 target.
143
144- *nfs:* Include NFS client support (for mounting NFS exports on
145 device).
146
147- *opengl:* Include the Open Graphics Library, which is a
148 cross-language, multi-platform application programming interface used
149 for rendering two and three-dimensional graphics.
150
151- *pci:* Include PCI bus support.
152
153- *pcmcia:* Include PCMCIA/CompactFlash support.
154
155- *ppp:* Include PPP dialup support.
156
157- *ptest:* Enables building the package tests where supported by
158 individual recipes. For more information on package tests, see the
159 ":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" section
160 in the Yocto Project Development Tasks Manual.
161
162- *smbfs:* Include SMB networks client support (for mounting
163 Samba/Microsoft Windows shares on device).
164
165- *systemd:* Include support for this ``init`` manager, which is a full
166 replacement of for ``init`` with parallel starting of services,
167 reduced shell overhead, and other features. This ``init`` manager is
168 used by many distributions.
169
170- *usbgadget:* Include USB Gadget Device support (for USB
171 networking/serial/storage).
172
173- *usbhost:* Include USB Host support (allows to connect external
174 keyboard, mouse, storage, network etc).
175
176- *usrmerge:* Merges the ``/bin``, ``/sbin``, ``/lib``, and ``/lib64``
177 directories into their respective counterparts in the ``/usr``
178 directory to provide better package and application compatibility.
179
180- *wayland:* Include the Wayland display server protocol and the
181 library that supports it.
182
183- *wifi:* Include WiFi support (integrated only).
184
185- *x11:* Include the X server and libraries.
186
187.. _ref-features-image:
188
189Image Features
190==============
191
192The contents of images generated by the OpenEmbedded build system can be
193controlled by the :term:`IMAGE_FEATURES` and
194:term:`EXTRA_IMAGE_FEATURES` variables that
195you typically configure in your image recipes. Through these variables,
196you can add several different predefined packages such as development
197utilities or packages with debug information needed to investigate
198application problems or profile applications.
199
200The following image features are available for all images:
201
202- *allow-empty-password:* Allows Dropbear and OpenSSH to accept root
203 logins and logins from accounts having an empty password string.
204
205- *dbg-pkgs:* Installs debug symbol packages for all packages installed
206 in a given image.
207
208- *debug-tweaks:* Makes an image suitable for development (e.g. allows
209 root logins without passwords and enables post-installation logging).
210 See the 'allow-empty-password', 'empty-root-password', and
211 'post-install-logging' features in this list for additional
212 information.
213
214- *dev-pkgs:* Installs development packages (headers and extra library
215 links) for all packages installed in a given image.
216
217- *doc-pkgs:* Installs documentation packages for all packages
218 installed in a given image.
219
220- *empty-root-password:* Sets the root password to an empty string,
221 which allows logins with a blank password.
222
223- *package-management:* Installs package management tools and preserves
224 the package manager database.
225
226- *post-install-logging:* Enables logging postinstall script runs to
227 the ``/var/log/postinstall.log`` file on first boot of the image on
228 the target system.
229
230 .. note::
231
232 To make the
233 /var/log
234 directory on the target persistent, use the
235 VOLATILE_LOG_DIR
236 variable by setting it to "no".
237
238- *ptest-pkgs:* Installs ptest packages for all ptest-enabled recipes.
239
240- *read-only-rootfs:* Creates an image whose root filesystem is
241 read-only. See the
242 ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
243 section in the Yocto Project Development Tasks Manual for more
244 information.
245
246- *splash:* Enables showing a splash screen during boot. By default,
247 this screen is provided by ``psplash``, which does allow
248 customization. If you prefer to use an alternative splash screen
249 package, you can do so by setting the ``SPLASH`` variable to a
250 different package name (or names) within the image recipe or at the
251 distro configuration level.
252
253- *staticdev-pkgs:* Installs static development packages, which are
254 static libraries (i.e. ``*.a`` files), for all packages installed in
255 a given image.
256
257Some image features are available only when you inherit the
258:ref:`core-image <ref-classes-core-image>` class. The current list of
259these valid features is as follows:
260
261- *hwcodecs:* Installs hardware acceleration codecs.
262
263- *nfs-server:* Installs an NFS server.
264
265- *perf:* Installs profiling tools such as ``perf``, ``systemtap``, and
266 ``LTTng``. For general information on user-space tools, see the
267 :doc:`../sdk-manual/sdk-manual` manual.
268
269- *ssh-server-dropbear:* Installs the Dropbear minimal SSH server.
270
271- *ssh-server-openssh:* Installs the OpenSSH SSH server, which is more
272 full-featured than Dropbear. Note that if both the OpenSSH SSH server
273 and the Dropbear minimal SSH server are present in
274 ``IMAGE_FEATURES``, then OpenSSH will take precedence and Dropbear
275 will not be installed.
276
277- *tools-debug:* Installs debugging tools such as ``strace`` and
278 ``gdb``. For information on GDB, see the
279 ":ref:`platdev-gdb-remotedebug`" section
280 in the Yocto Project Development Tasks Manual. For information on
281 tracing and profiling, see the :doc:`../profile-manual/profile-manual`.
282
283- *tools-sdk:* Installs a full SDK that runs on the device.
284
285- *tools-testapps:* Installs device testing tools (e.g. touchscreen
286 debugging).
287
288- *x11:* Installs the X server.
289
290- *x11-base:* Installs the X server with a minimal environment.
291
292- *x11-sato:* Installs the OpenedHand Sato environment.
293
294.. _ref-features-backfill:
295
296Feature Backfilling
297===================
298
299Sometimes it is necessary in the OpenEmbedded build system to extend
300:term:`MACHINE_FEATURES` or
301:term:`DISTRO_FEATURES` to control functionality
302that was previously enabled and not able to be disabled. For these
303cases, we need to add an additional feature item to appear in one of
304these variables, but we do not want to force developers who have
305existing values of the variables in their configuration to add the new
306feature in order to retain the same overall level of functionality.
307Thus, the OpenEmbedded build system has a mechanism to automatically
308"backfill" these added features into existing distro or machine
309configurations. You can see the list of features for which this is done
310by finding the
311:term:`DISTRO_FEATURES_BACKFILL` and
312:term:`MACHINE_FEATURES_BACKFILL`
313variables in the ``meta/conf/bitbake.conf`` file.
314
315Because such features are backfilled by default into all configurations
316as described in the previous paragraph, developers who wish to disable
317the new features need to be able to selectively prevent the backfilling
318from occurring. They can do this by adding the undesired feature or
319features to the
320:term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
321or
322:term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`
323variables for distro features and machine features respectively.
324
325Here are two examples to help illustrate feature backfilling:
326
327- *The "pulseaudio" distro feature option*: Previously, PulseAudio
328 support was enabled within the Qt and GStreamer frameworks. Because
329 of this, the feature is backfilled and thus enabled for all distros
330 through the ``DISTRO_FEATURES_BACKFILL`` variable in the
331 ``meta/conf/bitbake.conf`` file. However, your distro needs to
332 disable the feature. You can disable the feature without affecting
333 other existing distro configurations that need PulseAudio support by
334 adding "pulseaudio" to ``DISTRO_FEATURES_BACKFILL_CONSIDERED`` in
335 your distro's ``.conf`` file. Adding the feature to this variable
336 when it also exists in the ``DISTRO_FEATURES_BACKFILL`` variable
337 prevents the build system from adding the feature to your
338 configuration's ``DISTRO_FEATURES``, effectively disabling the
339 feature for that particular distro.
340
341- *The "rtc" machine feature option*: Previously, real time clock (RTC)
342 support was enabled for all target devices. Because of this, the
343 feature is backfilled and thus enabled for all machines through the
344 ``MACHINE_FEATURES_BACKFILL`` variable in the
345 ``meta/conf/bitbake.conf`` file. However, your target device does not
346 have this capability. You can disable RTC support for your device
347 without affecting other machines that need RTC support by adding the
348 feature to your machine's ``MACHINE_FEATURES_BACKFILL_CONSIDERED``
349 list in the machine's ``.conf`` file. Adding the feature to this
350 variable when it also exists in the ``MACHINE_FEATURES_BACKFILL``
351 variable prevents the build system from adding the feature to your
352 configuration's ``MACHINE_FEATURES``, effectively disabling RTC
353 support for that particular machine.