diff options
author | Patrick Williams <patrick@stwcx.xyz> | 2021-01-30 17:17:16 +0300 |
---|---|---|
committer | Patrick Williams <patrick@stwcx.xyz> | 2021-01-30 17:19:34 +0300 |
commit | bf91d30bc84e7159f13d32da1bc4007fbfdb8a6e (patch) | |
tree | 25a46ba775bf2e8d4aab4c329446eefc6d326551 /poky/documentation/overview-manual/overview-manual-yp-intro.xml | |
parent | 94a70a0f73533c9af5a5a15942539e8eda1a6a5e (diff) | |
download | openbmc-bf91d30bc84e7159f13d32da1bc4007fbfdb8a6e.tar.xz |
subtree updates
poky: 424296bf9b..7ea41de137:
Adrian Herrera (1):
scripts: oe-run-native, fix *-native directories
Alexander Kanavin (8):
meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
llvm: fix reproducibility
ruby: fix reproducibility
webkitgtk: fix reproducibility
ffmpeg: fix reproducibility
serf: do not install the static library
llvm: sort the lists in generated source reproducibibly
valgrind: exclude bar_bad/bar_bad_xml from ptests
Andrej Valek (2):
kernel-dummy: fix executing unexpected tasks
python3: fix CVE-2019-20907
Andrey Mozzhuhin (1):
toolchain-shar-extract.sh: Handle special characters in script path
Anuj Mittal (2):
distutils-common-base: fix LINKSHARED expansion
mesa: add more details to elf-tls patch
Armin Kuster (2):
xorg: Security fix for CVE-2020-14345
glibc: Security fix for CVE-2020-29573
Brett Warren (1):
libffi: add patch to revert clang VFP workaround
Bruce Ashfield (20):
kernel: provide module.lds for out of tree builds in v5.10+
kernel: relocate copy of module.lds to module compilation task
linux-yocto/5.4: update to v5.4.71
linux-yocto/5.4: update to v5.4.72
linux-yocto/5.4: update to v5.4.73
linux-yocto/5.4: config cleanup / warnings
linux-yocto/5.4: update to v5.4.75
linux-yocto/5.4: perf: Alias SYS_futex with SYS_futex_time64 on 32-bit arches with 64bit time_t
linux-yocto/5.4: update to v5.4.78
lttng-modules: add post 2.11.6 patches
linux-yocto-rt/5.4: update to -rt44
linux-yocto/5.4: update to v5.4.80
linux-yocto/cfg: qemuppc: set CONFIG_SCSI to '=y'
linux-yocto/5.4: update to v5.4.82
linux-yocto/cfg: qemuarm64-gfx.cfg: add CONFIG_INPUT_UINPUT
linux-yocto/5.4: update to v5.4.83
linux-yocto/5.4/cfg: fix -tiny warnings
linux-yocto/5.4/cfg: fix FIRMWARE_LOADER warnings
linux-yocto/5.4: update to v5.4.85
linux-yocto/5.4: update to v5.4.87
Changqing Li (2):
buildtools-tarball: add wic dependency into extended buildtools
libexif: fix CVE-2020-0198; CVE-2020-0452
Chris Laplante (1):
systemd.bbclass: improve error message when a service unit specified in SYSTEMD_SERVICE is not found
Christopher Larson (2):
grub-efi-cfg: exclude OVERRIDES from build_efi_cfg vardeps
uboot-extlinux-config: exclude OVERRIDES from do_create_extlinux_config vardeps
Daniel Ammann (1):
wic: fix typo
Diego Sueiro (1):
modutils-initscripts: Use depmod -a when modules.dep is empty
Dmitry Baryshkov (5):
linux-firmware: upgrade 20201022 -> 20201118
linux-firmware: package ath11k firmware
linux-firmware: upgrade 20201118 -> 20201218
linux-firmware: package firmware for Lontium lt9611uxc bridge
perl: fix installation failure because of shell issue
Fedor Ross (2):
sysvinit: remove bashism to be compatible with dash
eudev: remove bashism to be compatible with dash
Gratian Crisan (1):
kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES
Hongxu Jia (1):
glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: add nativesdk support
Joshua Watt (4):
ref-variables: Given example for naming sources
ref-manual: Document wic --offset option
documentation: Add Pipenv support
classes/waf: Add build and install arguments
Khem Raj (1):
initscripts: use quotes for shell variable comparision
Lee Chee Yang (7):
go: update to 1.14.12
glibc: fix CVE-2020-29562
qemu: fix CVE-2020-25723
binutils: fix CVE-2020-16592/16598
wic/direct/kparser: ensure fsuuid for vfat and msdos align with format
gdk-pixbuf: fix CVE-2020-29385
curl: fix CVE-2020-8231/8284/8285/8286
Loic Domaigne (1):
roofs_*.bbclass: fix missing vardeps for do_rootfs
Mans Rullgard (1):
boost: drop arm-intrinsics.patch
Marek Vasut (2):
meta: toolchain-shar-relocate.sh: Do not use $target_sdk_dir as regex
meta: toolchain-shar-relocate.sh: Filter out post-relocate-setup script
Mark Jonas (1):
libsdl2: Add directfb to PACKAGECONFIG rdepends
Max Krummenacher (1):
linux-firmware: rdepend on license for all nvidia packages
Maxime Roussin-Bélanger (1):
meta: add missing descriptions in some support recipes
Mert Kirpici (1):
bitbake: doc/conf.py: add missing import sys
Michael Ho (1):
license_image.bbclass: fix missing recipeinfo on self
Mikko Rapeli (4):
glibc: update to 2.31 stable tree head
glib-2.0: add patch for CVE-2020-35457
systemd: update from 244.3 to 244.5 stable release
zip: whitelist CVE-2018-13410 and CVE-2018-13684
Milan Shah (1):
oe-pkgdata-util: Added a test to verify oe-pkgdata-util without parameters
Naoki Hayama (1):
dev/test/ref-manual: Fix typos
Nathan Rossi (2):
ncurses: Prevent LDFLAGS being emitted in .pc files
coreutils: enable xattrs by default for nativesdk
Nicolas Dechesne (16):
bitbake: sphinx: import sphinx docs
bitbake: sphinx: undo (bitbake-user-manual: Remove TERM from BB_HASHBASE_WHITELIST example)
bitbake: sphinx: partial undo (bitbake-user-manual: update perforce fetcher docs)
sphinx: import docs
sphinx: undo (ref-system-requirements: update supported hosts lists)
sphinx: reintroduce changes for 3.1.1, 3.1.2, 3.1.3 and 3.1.4
sphinx: remove test-manual
sphinx: fix up some trademark and branding issues
sphinx: remove DocBook files
sphinx: rename Makefile.sphinx
sdk-manual: use built-in footnotes
sphinx: add 3.1.3 and 3.0.4 release in the switcher
poky.yaml: remove unused variables
Makefile: enable parallel build
conf.py: set version to 3.1.4
sphinx: update link to bitbake docs
Ovidiu Panait (2):
timezone: upgrade to 2020e
timezone: upgrade to 2020f
Paul Barker (2):
conf.py: Improve TOC and Outline depth in PDF output
selftest: Add argument to keep build dir
Paul Eggleton (5):
ref-manual: add reference anchors for each QA check
ref-manual: fix for features_check class change
ref-manual: add IMAGE_VERSION_SUFFIX variable
ref-manual: add IMAGE_NAME_SUFFIX variable
ref-manual: add IMAGE_LINK_NAME
Peter Kjellerstedt (1):
apr-util: Only specify --with-dbm=gdbm if gdbm support is enabled
Quentin Schulz (20):
docs: ref-manual: ref-variables: fix one-letter pointer links in glossary
docs: ref-manual: ref-variables: fix alphabetical order in glossary
docs: ref-manual: ref-variables: add links to terms in glossary
docs: poky.yaml: use HTTPS for links
docs: ref-manual: indentation, links and highlights fixes
docs: remove OE_INIT_FILE variable
docs: ref-manual: fix typos
docs: ref-manual: migration-2.3: specify 2.3 version instead of DISTRO
docs: ref-manual: ref-classes: remove dropped tinderclient class
docs: ref-manual: ref-system-requirements: update requirements to build Sphinx docs
docs: sphinx: yocto-vars: rebuild files when poky.yaml has changed
docs: poky.yaml: fix identation in host packages variables
docs: dev-manual-common-tasks: remove paragraph about race when missing DEPENDS
docs: dev-manual-common-tasks: update python webserver example to python3
docs: dev-manual: fix typos, highlights, indentation and links
docs: ref-manual: ref-terms: add links to terms in glossary
docs: bsp-guide: bsp: fix typos, highlights and links
docs: kernel-dev: fix typos, highlights and links
docs: kernel-dev-common: add .patch file extension to SRC_URI files
docs: kernel-dev-faq: update outdated RDEPENDS_kernel-base
Richard Purdie (20):
fs-perms: Ensure /usr/src/debug/ file modes are correct
e2fsprogs: Fix a ptest permissions determinism issue
lz4: Use the new branch naming from upstream
metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
grub: Fix build reproducibility issue
grub: Add second fix for determinism issue
u-boot-tools: Fix reproducibility issue
groff: Fix reproducibility issue
man-db: Avoid reproducibility failures after fixing groff-native
cups: Mark CVE-2009-0032 as a non-issue
cups: Mark CVE-2008-1033 as a non-issue
docs: Fix license CC-BY-2.0-UK -> CC-BY-SA-2.0-UK
ref-manual/faq: Add entry for why binaries are changed in images
dev-manual: Add a note about prelink changing prebuild binaries
oeqa/commands: Ensure sync can be found regardless of PATH
grub: Further reproducibility fix
man-db: Fix reproducibility issue
gcc: Fix mangled patch
bitbake: data_smart: Ensure hash reflects vardepvalue flags correctly
linuxloader: Avoid confusing string concat errors
Robert Joslyn (2):
openssl: Update to 1.1.1i
ppp: Whitelist CVE-2020-15704
Robert P. J. Day (3):
ref-manual/ref-variables: "PACKAGE_FEEDS_ARCHS" -> "PACKAGE_FEED_ARCHS"
README: "yocto-project-qs" -> "brief-yoctoprojectqs"
adt-manual: delete obsolete ADT manual, and related content
Robert Yang (5):
buildtools-tarball.bb: Fix PATH for environment setup script
ncurses: Make ncurses-tools depend on ncurses-terminfo-base
minicom: RDEPENDS on ncurses-terminfo-base
archiver.bbclass: Fix --runall=deploy_archives for images
weston: Fix PACKAGECONFIG for remoting
Ross Burton (17):
bitbake: taskexp: update for GTK API changes
cve-check: show real PN/PV
python3: add CVE-2007-4559 to whitelist
gstreamer1.0-rtsp-server: set CVE_PRODUCT
gstreamer1.0-plugins-base: set CVE_PRODUCT
oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
devtool: remove unused variable
image_types: sort tarball file listings
cve-update-db-native: handle all-wildcard versions
coreutils: add SUSE-specific issues to CVE whitelist
kernel: set COMPATIBLE_HOST to *-linux
ncurses: remove config.cache
wic-image-minimal: only depend on syslinux on x86 targets
lib/oe/qa: handle the 'no specific instruction set' ELF e_machine value
diffstat: point the license checksum at the license
ruby: remove tcl DEPENDS
waf: don't assume the waf intepretter is good
Scott Murray (3):
grub: fix "CVE:" line in one of the patches
patch: fix CVE-2019-20633
glibc: CVE-2019-25013
Steve Sakoman (5):
sqlite3: add CVE-2015-3717 to whitelist
oeqa/selftest/cases/devtool.py: fix typo in ignore_patterns call
cups: whitelist CVE-2018-6553
documentation: prepare for 3.1.5 release
poky.conf: Bump version for 3.1.5 release
Tanu Kaskinen (1):
pulseaudio: Remove OE_LT_RPATH_ALLOW
Thomas Perrot (1):
go.bbclass: don't stage test data with sources of dependencies
Tomasz Dziendzielski (2):
populate_sdk_base: Fix condition syntax if SDK_RELOCATE_AFTER_INSTALL is disabled
lib/oe/utils: Return empty string in parallel_make
Vyacheslav Yurkov (1):
license_image.bbclass: use canonical name for license files
Wang Mingyu (1):
mobile-broadband-provider-info: upgrade 20190618 ->20201225
Wonmin Jung (1):
kernel: Set proper LD in KERNEL_KCONFIG_COMMAND
sangeeta jain (1):
meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell
zangrc (2):
wireless-regdb: upgrade 2020.04.29 -> 2020.11.20
bash: Rename patch name
meta-openembedded: f2d02cb71e..5bba79488b:
Armin Kuster (5):
wireguard-module: fix build issue with 5.4 kernel
mariadb: update to 10.4.17 for cve fixes
lua: update to 5.3.6
nss: Security fix CVE-2020-12401
wireshark: Several securtiy fixes
Chenxi Mao (1):
geoclue: select avahi-daemon if nmea enabled
Diego Santa Cruz (2):
gssdp: Upgrade to 1.2.2 -> 1.2.3
gupnp: Upgrade to 1.2.2 -> 1.2.4
Gianfranco (1):
dlt-daemon: add upstream patch to fix CVE-2020-29394
Khem Raj (4):
nodejs: Fix build with icu 67.1
nodejs: Upgrade to 12.18.3
nodejs: Fix arm32/thumb builds with clang
nodejs: Update to 12.19.0
Leon Anavi (1):
php: Upgrade 7.4.4 -> 7.4.9
Max Kellermann (1):
php: remove the failing ${D}/${TMPDIR} code
Robert Joslyn (1):
postgresql: Update to 12.5
Roland Hieber (1):
pcsc-lite: provide pcsc-lite-lib-native explicitly for native build
Sakib Sajal (1):
apache2: upgrade v2.4.43 -> v2.4.46
Sean Nyekjaer (1):
nodejs: 12.19.1 -> 12.20.1
Stacy Gaikovaia (1):
nodejs: 12.19.0 -> 12.19.1
Wang Mingyu (1):
zabbix: CVE-2020-15803 Security Advisory
Wenlin Kang (2):
lua: fix CVE-2020-15945
lua: fix CVE-2020-24371
Zang Ruochen (1):
mcpp: Normalize the patch format of CVE
Zheng Ruoqin (4):
samba: CVE-2020-14318 Security Advisory
samba: CVE-2020-14383 Security Advisory
php: CVE-2020-7070
php: CVE-2020-7069
jabdoa2 (2):
libsdl2-mixer: Fix ogg/vorbis support in libsdl2-mixer
libsdl2-mixer: set --disable-music-ogg-shared to link statically
viatsk (1):
tcpdump: Patch for CVE-2020-8037
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I6e3b58075efc33fcfd6e9e1aa697f8763b5a89aa
Diffstat (limited to 'poky/documentation/overview-manual/overview-manual-yp-intro.xml')
-rw-r--r-- | poky/documentation/overview-manual/overview-manual-yp-intro.xml | 1332 |
1 files changed, 0 insertions, 1332 deletions
diff --git a/poky/documentation/overview-manual/overview-manual-yp-intro.xml b/poky/documentation/overview-manual/overview-manual-yp-intro.xml deleted file mode 100644 index 1b60a30302..0000000000 --- a/poky/documentation/overview-manual/overview-manual-yp-intro.xml +++ /dev/null @@ -1,1332 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > - -<chapter id='overview-yp'> - <title>Introducing the Yocto Project</title> - - <section id='what-is-the-yocto-project'> - <title>What is the Yocto Project?</title> - - <para> - The Yocto Project is an open source collaboration project - that helps developers create custom Linux-based systems that are - designed for embedded products regardless of the product's hardware - architecture. - Yocto Project provides a flexible toolset and a development - environment that allows embedded device developers across the - world to collaborate through shared technologies, software stacks, - configurations, and best practices used to create these tailored - Linux images. - </para> - - <para> - Thousands of developers worldwide have discovered that Yocto - Project provides advantages in both systems and applications - development, archival and management benefits, and customizations - used for speed, footprint, and memory utilization. - The project is a standard when it comes to delivering embedded - software stacks. - The project allows software customizations and build interchange - for multiple hardware platforms as well as software stacks that - can be maintained and scaled. - </para> - - <para id='yp-key-dev-elements'> - <imagedata fileref="figures/key-dev-elements.png" format="PNG" align='center' width="8in"/> - </para> - - <para> - For further introductory information on the Yocto Project, you - might be interested in this - <ulink url='https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project-'>article</ulink> - by Drew Moseley and in this short introductory - <ulink url='https://www.youtube.com/watch?v=utZpKM7i5Z4'>video</ulink>. - </para> - - <para> - The remainder of this section overviews advantages and challenges - tied to the Yocto Project. - </para> - - <section id='gs-features'> - <title>Features</title> - - <para> - The following list describes features and advantages of the - Yocto Project: - <itemizedlist> - <listitem><para> - <emphasis>Widely Adopted Across the Industry:</emphasis> - Semiconductor, operating system, software, and - service vendors exist whose products and services - adopt and support the Yocto Project. - For a look at the Yocto Project community and - the companies involved with the Yocto - Project, see the "COMMUNITY" and "ECOSYSTEM" tabs - on the - <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> - home page. - </para></listitem> - <listitem><para> - <emphasis>Architecture Agnostic:</emphasis> - Yocto Project supports Intel, ARM, MIPS, AMD, PPC - and other architectures. - Most ODMs, OSVs, and chip vendors create and supply - BSPs that support their hardware. - If you have custom silicon, you can create a BSP - that supports that architecture.</para> - - <para>Aside from lots of architecture support, the - Yocto Project fully supports a wide range of device - emulation through the Quick EMUlator (QEMU). - </para></listitem> - <listitem><para> - <emphasis>Images and Code Transfer Easily:</emphasis> - Yocto Project output can easily move between - architectures without moving to new development - environments. - Additionally, if you have used the Yocto Project to - create an image or application and you find yourself - not able to support it, commercial Linux vendors such - as Wind River, Mentor Graphics, Timesys, and ENEA could - take it and provide ongoing support. - These vendors have offerings that are built using - the Yocto Project. - </para></listitem> - <listitem><para> - <emphasis>Flexibility:</emphasis> - Corporations use the Yocto Project many different ways. - One example is to create an internal Linux distribution - as a code base the corporation can use across multiple - product groups. - Through customization and layering, a project group - can leverage the base Linux distribution to create - a distribution that works for their product needs. - </para></listitem> - <listitem><para> - <emphasis>Ideal for Constrained Embedded and IoT devices:</emphasis> - Unlike a full Linux distribution, you can use the - Yocto Project to create exactly what you need for - embedded devices. - You only add the feature support or packages that you - absolutely need for the device. - For devices that have display hardware, you can use - available system components such as X11, GTK+, Qt, - Clutter, and SDL (among others) to create a rich user - experience. - For devices that do not have a display or where you - want to use alternative UI frameworks, you can choose - to not install these components. - </para></listitem> - <listitem><para> - <emphasis>Comprehensive Toolchain Capabilities:</emphasis> - Toolchains for supported architectures satisfy most - use cases. - However, if your hardware supports features that are - not part of a standard toolchain, you can easily - customize that toolchain through specification of - platform-specific tuning parameters. - And, should you need to use a third-party toolchain, - mechanisms built into the Yocto Project allow for that. - </para></listitem> - <listitem><para> - <emphasis>Mechanism Rules Over Policy:</emphasis> - Focusing on mechanism rather than policy ensures that - you are free to set policies based on the needs of your - design instead of adopting decisions enforced by some - system software provider. - </para></listitem> - <listitem><para> - <emphasis>Uses a Layer Model:</emphasis> - The Yocto Project - <link linkend='the-yocto-project-layer-model'>layer infrastructure</link> - groups related functionality into separate bundles. - You can incrementally add these grouped functionalities - to your project as needed. - Using layers to isolate and group functionality - reduces project complexity and redundancy, allows you - to easily extend the system, make customizations, - and keep functionality organized. - </para></listitem> - <listitem><para> - <emphasis>Supports Partial Builds:</emphasis> - You can build and rebuild individual packages as - needed. - Yocto Project accomplishes this through its - <link linkend='shared-state-cache'>shared-state cache</link> - (sstate) scheme. - Being able to build and debug components individually - eases project development. - </para></listitem> - <listitem><para> - <emphasis>Releases According to a Strict Schedule:</emphasis> - Major releases occur on a - <ulink url='&YOCTO_DOCS_REF_URL;#ref-release-process'>six-month cycle</ulink> - predictably in October and April. - The most recent two releases support point releases - to address common vulnerabilities and exposures. - This predictability is crucial for projects based on - the Yocto Project and allows development teams to - plan activities. - </para></listitem> - <listitem><para> - <emphasis>Rich Ecosystem of Individuals and Organizations:</emphasis> - For open source projects, the value of community is - very important. - Support forums, expertise, and active developers who - continue to push the Yocto Project forward are readily - available. - </para></listitem> - <listitem><para> - <emphasis>Binary Reproducibility:</emphasis> - The Yocto Project allows you to be very specific about - dependencies and achieves very high percentages of - binary reproducibility (e.g. 99.8% for - <filename>core-image-minimal</filename>). - When distributions are not specific about which - packages are pulled in and in what order to support - dependencies, other build systems can arbitrarily - include packages. - </para></listitem> - <listitem><para> - <emphasis>License Manifest:</emphasis> - The Yocto Project provides a - <ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>license manifest</ulink> - for review by people who need to track the use of open - source licenses (e.g.legal teams). - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-challenges'> - <title>Challenges</title> - - <para> - The following list presents challenges you might encounter - when developing using the Yocto Project: - <itemizedlist> - <listitem><para> - <emphasis>Steep Learning Curve:</emphasis> - The Yocto Project has a steep learning curve and has - many different ways to accomplish similar tasks. - It can be difficult to choose how to proceed when - varying methods exist by which to accomplish a given - task. - </para></listitem> - <listitem><para> - <emphasis>Understanding What Changes You Need to Make - For Your Design Requires Some Research:</emphasis> - Beyond the simple tutorial stage, understanding what - changes need to be made for your particular design - can require a significant amount of research and - investigation. - For information that helps you transition from - trying out the Yocto Project to using it for your - project, see the - "<ulink url='&YOCTO_DOCS_URL;/what-i-wish-id-known/'>What I wish I'd Known</ulink>" - and - "<ulink url='&YOCTO_DOCS_URL;/transitioning-to-a-custom-environment/'>Transitioning to a Custom Environment for Systems Development</ulink>" - documents on the Yocto Project website. - </para></listitem> - <listitem><para> - <emphasis>Project Workflow Could Be Confusing:</emphasis> - The - <link linkend='overview-development-environment'>Yocto Project workflow</link> - could be confusing if you are used to traditional - desktop and server software development. - In a desktop development environment, mechanisms exist - to easily pull and install new packages, which are - typically pre-compiled binaries from servers accessible - over the Internet. - Using the Yocto Project, you must modify your - configuration and rebuild to add additional packages. - </para></listitem> - <listitem><para> - <emphasis>Working in a Cross-Build Environment Can - Feel Unfamiliar:</emphasis> - When developing code to run on a target, compilation, - execution, and testing done on the actual target - can be faster than running a BitBake build on a - development host and then deploying binaries to the - target for test. - While the Yocto Project does support development tools - on the target, the additional step of integrating your - changes back into the Yocto Project build environment - would be required. - Yocto Project supports an intermediate approach that - involves making changes on the development system - within the BitBake environment and then deploying only - the updated packages to the target.</para> - - <para>The Yocto Project - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - produces packages in standard formats (i.e. RPM, - DEB, IPK, and TAR). - You can deploy these packages into the running system - on the target by using utilities on the target such - as <filename>rpm</filename> or - <filename>ipk</filename>. - </para></listitem> - <listitem><para> - <emphasis>Initial Build Times Can be Significant:</emphasis> - Long initial build times are unfortunately unavoidable - due to the large number of packages initially built - from scratch for a fully functioning Linux system. - Once that initial build is completed, however, the - shared-state (sstate) cache mechanism Yocto Project - uses keeps the system from rebuilding packages that - have not been "touched" since the last build. - The sstate mechanism significantly reduces times - for successive builds. - </para></listitem> - </itemizedlist> - </para> - </section> - </section> - - <section id='the-yocto-project-layer-model'> - <title>The Yocto Project Layer Model</title> - - <para> - The Yocto Project's "Layer Model" is a development model for - embedded and IoT Linux creation that distinguishes the - Yocto Project from other simple build systems. - The Layer Model simultaneously supports collaboration and - customization. - Layers are repositories that contain related sets of instructions - that tell the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - what to do. - You can collaborate, share, and reuse layers. - </para> - - <para> - Layers can contain changes to previous instructions or settings - at any time. - This powerful override capability is what allows you to customize - previously supplied collaborative or community layers to suit your - product requirements. - </para> - - <para> - You use different layers to logically separate information in your - build. - As an example, you could have BSP, GUI, distro configuration, - middleware, or application layers. - Putting your entire build into one layer limits and complicates - future customization and reuse. - Isolating information into layers, on the other hand, helps - simplify future customizations and reuse. - You might find it tempting to keep everything in one layer when - working on a single project. - However, the more modular your Metadata, the easier - it is to cope with future changes. - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - Use Board Support Package (BSP) layers from silicon - vendors when possible. - </para></listitem> - <listitem><para> - Familiarize yourself with the - <ulink url='https://caffelli-staging.yoctoproject.org/software-overview/layers/'>Yocto Project curated layer index</ulink> - or the - <ulink url='http://layers.openembedded.org/layerindex/branch/master/layers/'>OpenEmbedded layer index</ulink>. - The latter contains more layers but they are less - universally validated. - </para></listitem> - <listitem><para> - Layers support the inclusion of technologies, hardware - components, and software components. - The - <ulink url='&YOCTO_DOCS_DEV_URL;#making-sure-your-layer-is-compatible-with-yocto-project'>Yocto Project Compatible</ulink> - designation provides a minimum level of standardization - that contributes to a strong ecosystem. - "YP Compatible" is applied to appropriate products and - software components such as BSPs, other OE-compatible - layers, and related open-source projects, allowing the - producer to use Yocto Project badges and branding - assets. - </para></listitem> - </itemizedlist> - </note> - </para> - - <para> - To illustrate how layers are used to keep things modular, consider - machine customizations. - These types of customizations typically reside in a special layer, - rather than a general layer, called a BSP Layer. - Furthermore, the machine customizations should be isolated from - recipes and Metadata that support a new GUI environment, - for example. - This situation gives you a couple of layers: one for the machine - configurations, and one for the GUI environment. - It is important to understand, however, that the BSP layer can - still make machine-specific additions to recipes within the GUI - environment layer without polluting the GUI layer itself - with those machine-specific changes. - You can accomplish this through a recipe that is a BitBake append - (<filename>.bbappend</filename>) file, which is described later - in this section. - <note> - For general information on BSP layer structure, see the - <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Packages (BSP) Developer's Guide</ulink>. - </note> - </para> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink> - contains both general layers and BSP layers right out of the box. - You can easily identify layers that ship with a Yocto Project - release in the Source Directory by their names. - Layers typically have names that begin with the string - <filename>meta-</filename>. - <note> - It is not a requirement that a layer name begin with the - prefix <filename>meta-</filename>, but it is a commonly - accepted standard in the Yocto Project community. - </note> - For example, if you were to examine the - <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/'>tree view</ulink> - of the <filename>poky</filename> repository, you will see several - layers: <filename>meta</filename>, - <filename>meta-skeleton</filename>, - <filename>meta-selftest</filename>, - <filename>meta-poky</filename>, and - <filename>meta-yocto-bsp</filename>. - Each of these repositories represents a distinct layer. - </para> - - <para> - For procedures on how to create layers, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> - </section> - - <section id='components-and-tools'> - <title>Components and Tools</title> - - <para> - The Yocto Project employs a collection of components and - tools used by the project itself, by project developers, - and by those using the Yocto Project. - These components and tools are open source projects and - metadata that are separate from the reference distribution - (<ulink url='&YOCTO_DOCS_REF_URL;#poky'>Poky</ulink>) - and the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>. - Most of the components and tools are downloaded separately. - </para> - - <para> - This section provides brief overviews of the components and - tools associated with the Yocto Project. - </para> - - <section id='gs-development-tools'> - <title>Development Tools</title> - - <para> - The following list consists of tools that help you develop - images and applications using the Yocto Project: - <itemizedlist> - <listitem><para id='gs-crops-overview'> - <emphasis>CROPS:</emphasis> - <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink> - is an open source, cross-platform development framework - that leverages - <ulink url='https://www.docker.com/'>Docker Containers</ulink>. - CROPS provides an easily managed, extensible environment - that allows you to build binaries for a variety of - architectures on Windows, Linux and Mac OS X hosts. - </para></listitem> - <listitem><para> - <emphasis><filename>devtool</filename>:</emphasis> - This command-line tool is available as part of the - extensible SDK (eSDK) and is its cornerstone. - You can use <filename>devtool</filename> to help build, - test, and package software within the eSDK. - You can use the tool to optionally integrate what you - build into an image built by the OpenEmbedded build - system.</para> - - <para>The <filename>devtool</filename> command employs - a number of sub-commands that allow you to add, modify, - and upgrade recipes. - As with the OpenEmbedded build system, “recipes” - represent software packages within - <filename>devtool</filename>. - When you use <filename>devtool add</filename>, a recipe - is automatically created. - When you use <filename>devtool modify</filename>, the - specified existing recipe is used in order to determine - where to get the source code and how to patch it. - In both cases, an environment is set up so that when - you build the recipe a source tree that is under your - control is used in order to allow you to make changes - to the source as desired. - By default, both new recipes and the source go into - a “workspace” directory under the eSDK. - The <filename>devtool upgrade</filename> command - updates an existing recipe so that you can build it - for an updated set of source files.</para> - - <para>You can read about the - <filename>devtool</filename> workflow in the Yocto - Project Application Development and Extensible - Software Development Kit (eSDK) Manual in the - "<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'>Using <filename>devtool</filename> in Your SDK Workflow'</ulink>" - section. - </para></listitem> - <listitem><para> - <emphasis>Extensible Software Development Kit (eSDK):</emphasis> - The eSDK provides a cross-development toolchain and - libraries tailored to the contents of a specific image. - The eSDK makes it easy to add new applications and - libraries to an image, modify the source for an - existing component, test changes on the target - hardware, and integrate into the rest of the - OpenEmbedded build system. - The eSDK gives you a toolchain experience supplemented - with the powerful set of <filename>devtool</filename> - commands tailored for the Yocto Project environment. - </para> - - <para>For information on the eSDK, see the - <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> - Manual. - </para></listitem> - <listitem><para> - <emphasis>Toaster:</emphasis> - Toaster is a web interface to the Yocto Project - OpenEmbedded build system. - Toaster allows you to configure, run, and view - information about builds. - For information on Toaster, see the - <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-production-tools'> - <title>Production Tools</title> - - <para> - The following list consists of tools that help production - related activities using the Yocto Project: - <itemizedlist> - <listitem><para> - <emphasis>Auto Upgrade Helper:</emphasis> - This utility when used in conjunction with the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - (BitBake and OE-Core) automatically generates upgrades - for recipes that are based on new versions of the - recipes published upstream. - </para></listitem> - <listitem><para> - <emphasis>Recipe Reporting System:</emphasis> - The Recipe Reporting System tracks recipe versions - available for Yocto Project. - The main purpose of the system is to help you - manage the recipes you maintain and to offer a dynamic - overview of the project. - The Recipe Reporting System is built on top of the - <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Layer Index</ulink>, - which is a website that indexes OpenEmbedded-Core - layers. - </para></listitem> - <listitem><para> - <emphasis>Patchwork:</emphasis> - <ulink url='http://jk.ozlabs.org/projects/patchwork/'>Patchwork</ulink> - is a fork of a project originally started by - <ulink url='http://ozlabs.org/'>OzLabs</ulink>. - The project is a web-based tracking system designed - to streamline the process of bringing contributions - into a project. - The Yocto Project uses Patchwork as an organizational - tool to handle patches, which number in the thousands - for every release. - </para></listitem> - <listitem><para> - <emphasis>AutoBuilder:</emphasis> - AutoBuilder is a project that automates build tests - and quality assurance (QA). - By using the public AutoBuilder, anyone can determine - the status of the current "master" branch of Poky. - <note> - AutoBuilder is based on - <ulink url='https://buildbot.net/'>buildbot</ulink>. - </note></para> - - <para>A goal of the Yocto Project is to lead the - open source industry with a project that automates - testing and QA procedures. - In doing so, the project encourages a development - community that publishes QA and test plans, publicly - demonstrates QA and test plans, and encourages - development of tools that automate and test and QA - procedures for the benefit of the development - community.</para> - - <para>You can learn more about the AutoBuilder used - by the Yocto Project - <ulink url='&YOCTO_AB_URL;'>here</ulink>. - </para></listitem> - <listitem><para> - <emphasis>Cross-Prelink:</emphasis> - Prelinking is the process of pre-computing the load - addresses and link tables generated by the dynamic - linker as compared to doing this at runtime. - Doing this ahead of time results in performance - improvements when the application is launched and - reduced memory usage for libraries shared by many - applications.</para> - - <para>Historically, cross-prelink is a variant of - prelink, which was conceived by - <ulink url='http://people.redhat.com/jakub/prelink.pdf'>Jakub Jelínek</ulink> - a number of years ago. - Both prelink and cross-prelink are maintained in the - same repository albeit on separate branches. - By providing an emulated runtime dynamic linker - (i.e. <filename>glibc</filename>-derived - <filename>ld.so</filename> emulation), the - cross-prelink project extends the prelink software’s - ability to prelink a sysroot environment. - Additionally, the cross-prelink software enables the - ability to work in sysroot style environments.</para> - - <para>The dynamic linker determines standard load - address calculations based on a variety of factors - such as mapping addresses, library usage, and library - function conflicts. - The prelink tool uses this information, from the - dynamic linker, to determine unique load addresses - for executable and linkable format (ELF) binaries - that are shared libraries and dynamically linked. - The prelink tool modifies these ELF binaries with the - pre-computed information. - The result is faster loading and often lower memory - consumption because more of the library code can - be re-used from shared Copy-On-Write (COW) pages. - </para> - - <para>The original upstream prelink project only - supports running prelink on the end target device - due to the reliance on the target device’s dynamic - linker. - This restriction causes issues when developing a - cross-compiled system. - The cross-prelink adds a synthesized dynamic loader - that runs on the host, thus permitting cross-prelinking - without ever having to run on a read-write target - filesystem. - </para></listitem> - <listitem><para> - <emphasis>Pseudo:</emphasis> - Pseudo is the Yocto Project implementation of - <ulink url='http://man.he.net/man1/fakeroot'>fakeroot</ulink>, - which is used to run commands in an environment - that seemingly has root privileges.</para> - - <para>During a build, it can be necessary to perform - operations that require system administrator - privileges. - For example, file ownership or permissions might need - definition. - Pseudo is a tool that you can either use directly or - through the environment variable - <filename>LD_PRELOAD</filename>. - Either method allows these operations to succeed as - if system administrator privileges exist even - when they do not.</para> - - <para>You can read more about Pseudo in the - "<link linkend='fakeroot-and-pseudo'>Fakeroot and Pseudo</link>" - section. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-openembedded-build-system'> - <title>Open-Embedded Build System Components</title> - - <para> - The following list consists of components associated with the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>: - <itemizedlist> - <listitem><para> - <emphasis>BitBake:</emphasis> - BitBake is a core component of the Yocto Project and is - used by the OpenEmbedded build system to build images. - While BitBake is key to the build system, BitBake - is maintained separately from the Yocto Project.</para> - - <para>BitBake is a generic task execution engine that - allows shell and Python tasks to be run efficiently - and in parallel while working within complex inter-task - dependency constraints. - In short, BitBake is a build engine that works - through recipes written in a specific format in order - to perform sets of tasks.</para> - - <para>You can learn more about BitBake in the - <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>. - </para></listitem> - <listitem><para> - <emphasis>OpenEmbedded-Core:</emphasis> - OpenEmbedded-Core (OE-Core) is a common layer of - metadata (i.e. recipes, classes, and associated files) - used by OpenEmbedded-derived systems, which includes - the Yocto Project. - The Yocto Project and the OpenEmbedded Project both - maintain the OpenEmbedded-Core. - You can find the OE-Core metadata in the Yocto Project - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta'>Source Repositories</ulink>. - </para> - - <para>Historically, the Yocto Project integrated the - OE-Core metadata throughout the Yocto Project - source repository reference system (Poky). - After Yocto Project Version 1.0, the Yocto Project - and OpenEmbedded agreed to work together and share a - common core set of metadata (OE-Core), which contained - much of the functionality previously found in Poky. - This collaboration achieved a long-standing - OpenEmbedded objective for having a more tightly - controlled and quality-assured core. - The results also fit well with the Yocto Project - objective of achieving a smaller number of fully - featured tools as compared to many different ones. - </para> - - <para>Sharing a core set of metadata results in Poky - as an integration layer on top of OE-Core. - You can see that in this - <link linkend='yp-key-dev-elements'>figure</link>. - The Yocto Project combines various components such as - BitBake, OE-Core, script “glue”, and documentation - for its build system. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-reference-distribution-poky'> - <title>Reference Distribution (Poky)</title> - - <para> - Poky is the Yocto Project reference distribution. - It contains the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink> - (BitBake and OE-Core) as well as a set of metadata to get you - started building your own distribution. - See the - <link linkend='what-is-the-yocto-project'>figure</link> in - "What is the Yocto Project?" section for an illustration - that shows Poky and its relationship with other parts of the - Yocto Project.</para> - - <para>To use the Yocto Project tools and components, you - can download (<filename>clone</filename>) Poky and use it - to bootstrap your own distribution. - <note> - Poky does not contain binary files. - It is a working example of how to build your own custom - Linux distribution from source. - </note> - You can read more about Poky in the - "<link linkend='reference-embedded-distribution'>Reference Embedded Distribution (Poky)</link>" - section. - </para> - </section> - - <section id='gs-packages-for-finished-targets'> - <title>Packages for Finished Targets</title> - - <para> - The following lists components associated with packages - for finished targets: - <itemizedlist> - <listitem><para> - <emphasis>Matchbox:</emphasis> - Matchbox is an Open Source, base environment for the - X Window System running on non-desktop, embedded - platforms such as handhelds, set-top boxes, kiosks, - and anything else for which screen space, input - mechanisms, or system resources are limited.</para> - - <para>Matchbox consists of a number of interchangeable - and optional applications that you can tailor to a - specific, non-desktop platform to enhance usability - in constrained environments.</para> - - <para>You can find the Matchbox source in the Yocto - Project - <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>. - </para></listitem> - <listitem><para> - <emphasis>Opkg</emphasis> - Open PacKaGe management (opkg) is a lightweight - package management system based on the itsy package - (ipkg) management system. - Opkg is written in C and resembles Advanced Package - Tool (APT) and Debian Package (dpkg) in operation. - </para> - - <para>Opkg is intended for use on embedded Linux - devices and is used in this capacity in the - <ulink url='http://www.openembedded.org/wiki/Main_Page'>OpenEmbedded</ulink> - and - <ulink url='https://openwrt.org/'>OpenWrt</ulink> - projects, as well as the Yocto Project. - <note> - As best it can, opkg maintains backwards - compatibility with ipkg and conforms to a subset - of Debian’s policy manual regarding control files. - </note> - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-archived-components'> - <title>Archived Components</title> - - <para> - The Build Appliance is a virtual machine image that enables - you to build and boot a custom embedded Linux image with - the Yocto Project using a non-Linux development system. - </para> - - <para> - Historically, the Build Appliance was the second of three - methods by which you could use the Yocto Project on a system - that was not native to Linux. - <orderedlist> - <listitem><para> - <emphasis>Hob:</emphasis> - Hob, which is now deprecated and is no longer available - since the 2.1 release of the Yocto Project provided - a rudimentary, GUI-based interface to the Yocto - Project. - Toaster has fully replaced Hob. - </para></listitem> - <listitem><para> - <emphasis>Build Appliance:</emphasis> - Post Hob, the Build Appliance became available. - It was never recommended that you use the Build - Appliance as a day-to-day production development - environment with the Yocto Project. - Build Appliance was useful as a way to try out - development in the Yocto Project environment. - </para></listitem> - <listitem><para> - <emphasis>CROPS:</emphasis> - The final and best solution available now for - developing using the Yocto Project on a system - not native to Linux is with - <link linkend='gs-crops-overview'>CROPS</link>. - </para></listitem> - </orderedlist> - </para> - </section> - </section> - - <section id='gs-development-methods'> - <title>Development Methods</title> - - <para> - The Yocto Project development environment usually involves a - <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink> - and target hardware. - You use the Build Host to build images and develop applications, - while you use the target hardware to test deployed software. - </para> - - <para> - This section provides an introduction to the choices or - development methods you have when setting up your Build Host. - Depending on the your particular workflow preference and the - type of operating system your Build Host runs, several choices - exist that allow you to use the Yocto Project. - <note> - For additional detail about the Yocto Project development - environment, see the - "<link linkend='overview-development-environment'>The Yocto Project Development Environment</link>" - chapter. - </note> - <itemizedlist> - <listitem><para> - <emphasis>Native Linux Host:</emphasis> - By far the best option for a Build Host. - A system running Linux as its native operating system - allows you to develop software by directly using the - <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> - tool. - You can accomplish all aspects of development from a - familiar shell of a supported Linux distribution.</para> - - <para>For information on how to set up a Build Host on - a system running Linux as its native operating system, - see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-a-native-linux-host'>Setting Up a Native Linux Host</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - <emphasis>CROss PlatformS (CROPS):</emphasis> - Typically, you use - <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink>, - which leverages - <ulink url='https://www.docker.com/'>Docker Containers</ulink>, - to set up a Build Host that is not running Linux (e.g. - <trademark class='registered'>Microsoft</trademark> - <trademark class='trademark'>Windows</trademark> - or - <trademark class='registered'>macOS</trademark>). - <note> - You can, however, use CROPS on a Linux-based system. - </note> - CROPS is an open source, cross-platform development - framework that provides an easily managed, extensible - environment for building binaries targeted for a variety - of architectures on Windows, macOS, or Linux hosts. - Once the Build Host is set up using CROPS, you can prepare - a shell environment to mimic that of a shell being used - on a system natively running Linux.</para> - - <para>For information on how to set up a Build Host with - CROPS, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops'>Setting Up to Use CROss PlatformS (CROPS)</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - <emphasis>Windows Subsystem For Linux (WSLv2):</emphasis> - You may use Windows Subsystem For Linux v2 to set up a build - host using Windows 10. - <note> - The Yocto Project is not compatible with WSLv1, it is - compatible but not officially supported nor validated - with WSLv2, if you still decide to use WSL please upgrade - to WSLv2. - </note> - The Windows Subsystem For Linux allows Windows 10 to run a real - Linux kernel inside of a lightweight utility virtual - machine (VM) using virtualization technology.</para> - <para>For information on how to set up a Build Host with - WSLv2, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - <emphasis>Toaster:</emphasis> - Regardless of what your Build Host is running, you can - use Toaster to develop software using the Yocto Project. - Toaster is a web interface to the Yocto Project's - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>. - The interface enables you to configure and run your - builds. - Information about builds is collected and stored in a - database. - You can use Toaster to configure and start builds on - multiple remote build servers.</para> - - <para>For information about and how to use Toaster, - see the - <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='reference-embedded-distribution'> - <title>Reference Embedded Distribution (Poky)</title> - - <para> - "Poky", which is pronounced <emphasis>Pock</emphasis>-ee, is the - name of the Yocto Project's reference distribution or Reference OS - Kit. - Poky contains the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded Build System</ulink> - (<ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> and - <ulink url='&YOCTO_DOCS_REF_URL;#oe-core'>OpenEmbedded-Core</ulink>) - as well as a set of - <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>metadata</ulink> to get - you started building your own distro. - In other words, Poky is a base specification of the functionality - needed for a typical embedded system as well as the components - from the Yocto Project that allow you to build a distribution into - a usable binary image. - </para> - - <para> - Poky is a combined repository of BitBake, OpenEmbedded-Core - (which is found in <filename>meta</filename>), - <filename>meta-poky</filename>, - <filename>meta-yocto-bsp</filename>, and documentation provided - all together and known to work well together. - You can view these items that make up the Poky repository in the - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/'>Source Repositories</ulink>. - <note> - If you are interested in all the contents of the - <filename>poky</filename> Git repository, see the - "<ulink url='&YOCTO_DOCS_REF_URL;#structure-core'>Top-Level Core Components</ulink>" - section in the Yocto Project Reference Manual. - </note> - </para> - - <para id='gs-poky-reference-distribution'> - The following figure illustrates what generally comprises Poky: - <imagedata fileref="figures/poky-reference-distribution.png" format="PNG" align='center' width="8in"/> - <itemizedlist> - <listitem><para> - BitBake is a task executor and scheduler that is the heart of - the OpenEmbedded build system. - </para></listitem> - <listitem><para> - <filename>meta-poky</filename>, which is Poky-specific - metadata. - </para></listitem> - <listitem><para> - <filename>meta-yocto-bsp</filename>, which are Yocto - Project-specific Board Support Packages (BSPs). - </para></listitem> - <listitem><para> - OpenEmbedded-Core (OE-Core) metadata, which includes - shared configurations, global variable definitions, - shared classes, packaging, and recipes. - Classes define the encapsulation and inheritance of build - logic. - Recipes are the logical units of software and images - to be built. - </para></listitem> - <listitem><para> - Documentation, which contains the Yocto Project source - files used to make the set of user manuals. - </para></listitem> - </itemizedlist> - <note> - While Poky is a "complete" distribution specification and is - tested and put through QA, you cannot use it as a product - "out of the box" in its current form. - </note> - </para> - - <para> - To use the Yocto Project tools, you can use Git to clone (download) - the Poky repository then use your local copy of the reference - distribution to bootstrap your own distribution. - <note> - Poky does not contain binary files. - It is a working example of how to build your own custom Linux distribution - from source. - </note> - </para> - - <para> - Poky has a regular, well established, six-month release cycle - under its own version. - Major releases occur at the same time major releases (point - releases) occur for the Yocto Project, which are typically in the - Spring and Fall. - For more information on the Yocto Project release schedule and - cadence, see the - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-release-process'>Yocto Project Releases and the Stable Release Process</ulink>" - chapter in the Yocto Project Reference Manual. - </para> - - <para> - Much has been said about Poky being a "default configuration." - A default configuration provides a starting image footprint. - You can use Poky out of the box to create an image ranging from a - shell-accessible minimal image all the way up to a Linux - Standard Base-compliant image that uses a GNOME Mobile and - Embedded (GMAE) based reference user interface called Sato. - </para> - - <para> - One of the most powerful properties of Poky is that every aspect - of a build is controlled by the metadata. - You can use metadata to augment these base image types by - adding metadata - <link linkend='the-yocto-project-layer-model'>layers</link> - that extend functionality. - These layers can provide, for example, an additional software - stack for an image type, add a board support package (BSP) for - additional hardware, or even create a new image type. - </para> - - <para> - Metadata is loosely grouped into configuration files or package - recipes. - A recipe is a collection of non-executable metadata used by - BitBake to set variables or define additional build-time tasks. - A recipe contains fields such as the recipe description, the recipe - version, the license of the package and the upstream source - repository. - A recipe might also indicate that the build process uses autotools, - make, distutils or any other build process, in which case the basic - functionality can be defined by the classes it inherits from - the OE-Core layer's class definitions in - <filename>./meta/classes</filename>. - Within a recipe you can also define additional tasks as well as - task prerequisites. - Recipe syntax through BitBake also supports both - <filename>_prepend</filename> and <filename>_append</filename> - operators as a method of extending task functionality. - These operators inject code into the beginning or end of a task. - For information on these BitBake operators, see the - "<ulink url='&YOCTO_DOCS_BB_URL;#appending-and-prepending-override-style-syntax'>Appending and Prepending (Override Style Syntax)</ulink>" - section in the BitBake User's Manual. - </para> - </section> - - <section id='openembedded-build-system-workflow'> - <title>The OpenEmbedded Build System Workflow</title> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - uses a "workflow" to accomplish image and SDK generation. - The following figure overviews that workflow: - <imagedata fileref="figures/YP-flow-diagram.png" - format="PNG" align='center' width="8in"/> - Following is a brief summary of the "workflow": - <orderedlist> - <listitem><para> - Developers specify architecture, policies, patches and - configuration details. - </para></listitem> - <listitem><para> - The build system fetches and downloads the source code - from the specified location. - The build system supports standard methods such as tarballs - or source code repositories systems such as Git. - </para></listitem> - <listitem><para> - Once source code is downloaded, the build system extracts - the sources into a local work area where patches are - applied and common steps for configuring and compiling - the software are run. - </para></listitem> - <listitem><para> - The build system then installs the software into a - temporary staging area where the binary package format you - select (DEB, RPM, or IPK) is used to roll up the software. - </para></listitem> - <listitem><para> - Different QA and sanity checks run throughout entire - build process. - </para></listitem> - <listitem><para> - After the binaries are created, the build system - generates a binary package feed that is used to create - the final root file image. - </para></listitem> - <listitem><para> - The build system generates the file system image and a - customized Extensible SDK (eSDK) for application - development in parallel. - </para></listitem> - </orderedlist> - </para> - - <para> - For a very detailed look at this workflow, see the - "<link linkend='openembedded-build-system-build-concepts'>OpenEmbedded Build System Concepts</link>" - section. - </para> - </section> - - - <section id='some-basic-terms'> - <title>Some Basic Terms</title> - - <para> - It helps to understand some basic fundamental terms when - learning the Yocto Project. - Although a list of terms exists in the - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-terms'>Yocto Project Terms</ulink>" - section of the Yocto Project Reference Manual, this section - provides the definitions of some terms helpful for getting started: - <itemizedlist> - <listitem><para> - <emphasis>Configuration Files:</emphasis> - Files that hold global definitions of variables, - user-defined variables, and hardware configuration - information. - These files tell the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink> - what to build and what to put into the image to support a - particular platform. - </para></listitem> - <listitem><para> - <emphasis>Extensible Software Development Kit (eSDK):</emphasis> - A custom SDK for application developers. - This eSDK allows developers to incorporate their library - and programming changes back into the image to make - their code available to other application developers. - For information on the eSDK, see the - <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> - manual. - </para></listitem> - <listitem><para> - <emphasis>Layer:</emphasis> - A collection of related recipes. - Layers allow you to consolidate related metadata to - customize your build. - Layers also isolate information used when building - for multiple architectures. - Layers are hierarchical in their ability to override - previous specifications. - You can include any number of available layers from the - Yocto Project and customize the build by adding your - layers after them. - You can search the Layer Index for layers used within - Yocto Project.</para> - - <para>For more detailed information on layers, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" - section in the Yocto Project Development Tasks Manual. - For a discussion specifically on BSP Layers, see the - "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" - section in the Yocto Project Board Support Packages (BSP) - Developer's Guide. - </para></listitem> - <listitem><para> - <emphasis>Metadata:</emphasis> - A key element of the Yocto Project is the Metadata that - is used to construct a Linux distribution and is contained - in the files that the OpenEmbedded build system parses - when building an image. - In general, Metadata includes recipes, configuration - files, and other information that refers to the build - instructions themselves, as well as the data used to - control what things get built and the effects of the - build. - Metadata also includes commands and data used to - indicate what versions of software are used, from - where they are obtained, and changes or additions to the - software itself (patches or auxiliary files) that - are used to fix bugs or customize the software for use - in a particular situation. - OpenEmbedded-Core is an important set of validated - metadata. - </para></listitem> - <listitem><para id='gs-term-openembedded-build-system'> - <emphasis>OpenEmbedded Build System:</emphasis> - The terms "BitBake" and "build system" are sometimes - used for the OpenEmbedded Build System.</para> - - <para>BitBake is a task scheduler and execution engine - that parses instructions (i.e. recipes) and configuration - data. - After a parsing phase, BitBake creates a dependency tree - to order the compilation, schedules the compilation of - the included code, and finally executes the building - of the specified custom Linux image (distribution). - BitBake is similar to the <filename>make</filename> - tool.</para> - - <para>During a build process, the build system tracks - dependencies and performs a native or cross-compilation - of the package. - As a first step in a cross-build setup, the framework - attempts to create a cross-compiler toolchain - (i.e. Extensible SDK) suited for the target platform. - </para></listitem> - <listitem><para> - <emphasis>OpenEmbedded-Core (OE-Core):</emphasis> - OE-Core is metadata comprised of foundation recipes, - classes, and associated files that are meant to be - common among many different OpenEmbedded-derived systems, - including the Yocto Project. - OE-Core is a curated subset of an original repository - developed by the OpenEmbedded community that has been - pared down into a smaller, core set of continuously - validated recipes. - The result is a tightly controlled and quality-assured - core set of recipes.</para> - - <para>You can see the Metadata in the - <filename>meta</filename> directory of the Yocto Project - <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Source Repositories</ulink>. - </para></listitem> - <listitem><para> - <emphasis>Packages:</emphasis> - In the context of the Yocto Project, this term refers to a - recipe's packaged output produced by BitBake (i.e. a - "baked recipe"). - A package is generally the compiled binaries produced from the - recipe's sources. - You "bake" something by running it through BitBake.</para> - - <para>It is worth noting that the term "package" can, - in general, have subtle meanings. - For example, the packages referred to in the - "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-build-host'>Required Packages for the Build Host</ulink>" - section in the Yocto Project Reference Manual are compiled - binaries that, when installed, add functionality to your - Linux distribution.</para> - - <para>Another point worth noting is that historically within - the Yocto Project, recipes were referred to as packages - thus, - the existence of several BitBake variables that are seemingly - mis-named, - (e.g. <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>, - <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, - and - <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>). - </para></listitem> - <listitem><para> - <emphasis>Poky:</emphasis> - Poky is a reference embedded distribution and a reference - test configuration. - Poky provides the following: - <itemizedlist> - <listitem><para> - A base-level functional distro used to illustrate - how to customize a distribution. - </para></listitem> - <listitem><para> - A means by which to test the Yocto Project - components (i.e. Poky is used to validate - the Yocto Project). - </para></listitem> - <listitem><para> - A vehicle through which you can download - the Yocto Project. - </para></listitem> - </itemizedlist> - Poky is not a product level distro. - Rather, it is a good starting point for customization. - <note> - Poky is an integration layer on top of OE-Core. - </note> - </para></listitem> - <listitem><para> - <emphasis>Recipe:</emphasis> - The most common form of metadata. - A recipe contains a list of settings and tasks - (i.e. instructions) for building packages that are then - used to build the binary image. - A recipe describes where you get source code and which - patches to apply. - Recipes describe dependencies for libraries or for other - recipes as well as configuration and compilation options. - Related recipes are consolidated into a layer. - </para></listitem> - </itemizedlist> - </para> - </section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> |