mirror of
git://git.yoctoproject.org/poky.git
synced 2025-07-19 21:09:03 +02:00
4b3ebf00dc
Created content for "What is the Yocto Project" section. Involved a new figure that had to be shared in the mega-manual figures folder. (From yocto-docs rev: 72c18abd11587f4d78848afb8a71ff7f4a0e76d0) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
303 lines
15 KiB
XML
303 lines
15 KiB
XML
<!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 hardware
|
|
support and software stacks, allowing software configuration
|
|
and build interchange, and build and support customizations for
|
|
multiple hardware platforms and software stacks that can be
|
|
maintained and scaled.
|
|
</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="figures/key-dev-elements.png"
|
|
format="PNG" align='center' width="8in"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
|
|
<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 companies involved with the Yocto
|
|
Project, see the membership, associate, and
|
|
participant pages on the Yocto Project 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></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.
|
|
</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 layer infrastructure 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.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Supports Partial Builds:</emphasis>
|
|
You can build and rebuild individual packages as
|
|
needed.
|
|
Yocto Project accomplishes this through its
|
|
shared-state cache (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 six-month cycle 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 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 license manifest for
|
|
review by people that 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 "What I wish I'd Known" and
|
|
"Transitioning to a Custom Environment for Systems
|
|
Development" documents on the Yocto Project website.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Project Workflow Could Be Confusing:</emphasis>
|
|
The Yocto Project workflow could be confusing if you
|
|
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 OpenEmbedded build system
|
|
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='what-are-layers'>
|
|
<title>What are Layers?</title>
|
|
|
|
</section>
|
|
|
|
<section id='components-and-tools'>
|
|
<title>Components and Tools</title>
|
|
|
|
</section>
|
|
|
|
<section id='the-development-environment'>
|
|
<title>The Development Environment</title>
|
|
|
|
</section>
|
|
|
|
<section id='reference-embedded-distribution'>
|
|
<title>Reference Embedded Distribution (Poky)</title>
|
|
|
|
</section>
|
|
|
|
<section id='the-yocto-project-workflow'>
|
|
<title>The Yocto Project Workflow</title>
|
|
|
|
</section>
|
|
|
|
|
|
<section id='some-basic-terms'>
|
|
<title>Some Basic Terms</title>
|
|
|
|
</section>
|
|
|
|
</chapter>
|
|
<!--
|
|
vim: expandtab tw=80 ts=4
|
|
-->
|