以下参考自CSDN博客，点击这里访问原文
- Yocto：Yocto是这个开源项目的名称，该项目旨在帮助我们自定义Linux系统
- Poky：Poky有两个含义。第一个含义是用来构建Linux的构建系统，值得注意的该Poky仅仅是一个概念，而非一个实体：它包含了 BitBake工具、编译工具链、BSP、诸多程序包或层，可以认为Poky即是Yocto的本质；此外Poky还有另外一层意思，使用Poky系统得到的默认参考 Linux 发行版也叫Poky（当然，我们可以对此发行版随意命名）。Poky的两个含义千万不能混淆
- Metadata：元数据集，所谓元数据集就是发行版内各基本元素的描述与来源
- Recipes：.bb/.bbappend文件，配方文件，描述了从哪获取软件源码，如何配置，如何编译。bbappend和bb的区别主要在于bbappend是基于bb的，功能是对相应的bb文件作补充和覆盖，有点类似于“重写”的概念
- Recipe: A set of instructions for building packages. A recipe describes where you get source code, which patches to apply, how to configure the source, how to compile it and so on. Recipes also describe dependencies for libraries or for other recipes. Recipes represent the logical unit of execution, the software to build, the images to build, and use the .bb file extension.
- Class：.bbclass文件
- Configuration：.conf文件，即配置文件，我们可以用它来改变构建方式
- Layers：即各种meta-xxx目录，将Metadata按层进行分类，有助于项目的维护
- Bitbake：一个任务执行引擎，用来解析并执行Metadata
- Output：即各种输出image
总结：假如用烹饪一桌酒席来形容构建发行版，则Yocto就是饭店名，Poky就是厨房（以及提供作为参考的菜的搭配套餐），Metadata就是烹饪资源（.bb/.bbappend表示配方/配方上的贴士，.conf表示厨房里的管事的小组长），Layers就是菜谱的分类（如川菜谱、粤菜谱），Bitbake就是厨师，Output就是得到的一桌酒席。
yocto项目结构
项目文件结构
sources文件结构
sources，layer结构
image.png
- 首先来分析一下目录结构，不难发现主要有三级构成：meta-xxx->recipes-yyy->zzz/ttt.bb。比如：meta-avi-> recipes-core->openssh-keys
- meta-fsl-arm：飞思卡尔官方推出的配方大全
- meta-openembedded：openembedded推出的配方大全
- meta-qt5：qt5官方推出的qt5配方大全
- poky中的一堆meta：yocto官方推出的参考配方。虽然这些meta被放在了poky里面，但是还是不影响使用的，他们具有和上面那些meta相同的地位
- 介绍完了layer，那么问题来了，那么是否可以认为，这些layer全部被enable了呢？答案固然是否定的
具体的layer选择由/base/conf/bblayers.conf负责，直观位置在前面目录中可以体现。仔细观察该文件，重点在BBLAYERS这个变量，里面有一些layer，这些layer就被enable了。
bblayers.conf
- 这些layer目前是被enable了，那么是否可以认为，这些layer中的配方也全部被使能了呢？答案固然是否定的，我们的发行版中不可能把所有的软件包放进去。在Yocto中，这个
选择配置操作是由好多个conf、bb文件协同完成的，并不存在一个总的大纲，这也是和buildroot最大的不同之处（buildroot是由menuconfig来进行大纲式的配置）。可以理解为Yocto是“分封制”，皇帝说的不一定能落实，具体还是各种大小地方官说了算；而buildroot是“中央集权制”，皇帝一人说了算 。
- 如何理解Yocto的配置方法？这要从发行版的定制流程说起。我们的目的很简单，是要得到uboot、kernel、rootfs这三个image；Yocto的目的也很简单，它要经过一级一级配置，逐步缩小配方，直至得到uboot、kernel、rootfs这三个image。每一级需要哪些配方，由该级对应的配置文件（conf/bb）决定。越上级的配置是越笼统的，越下级的配置越细致。如果下级的配置项相对于上级有补充或者冲突，则以下级的内容为准，可以认为下级会对上级进行“重写”。这其实有点类似交通法规
原文配图
- 有关构建的路线和流程：对于整个发行版构建，虽然每一级的配方由（conf/bb）决定，但是每一级路线和方向的选择，是由我们最终bitbake的对象决定的，比如我们最终bitbake avi-image-core，我们想要获得rootfs.img，那么：
- 第一步Poky就会从local.conf开始，一路向下，一级一级配置，直到配置到和rootfs有关的那一堆bb，最终形成完整完全的配方
- 然后获取配方需要的资源，比如各种软件包，比如kernel的源码
- 最后把所有的资源编译出我们需要的镜像
原文配图
- 最后说一下bitbake，比如我们要选择编译rootfs.img，那么使用bitbake avi-image-core即可，但是很多时候并不直接采用这种做法。大多数情况下我们会在项目目录下写一个Makefile，里面包含各种各样的功能，内部以bitbake指令实现
