Yocto理论篇 Yocto共享状态缓存_yocto ${workdir}

使问题复杂化的是，有些东西不应该包括在校验和中。首先，有一个给定任务的实际特定构建路径—WORKDIR。工作目录是否更改并不重要，因为它不应影响目标包的输出。此外，构建过程的目标是使本机包或跨包可重定位。

注意：本机包和交叉包都在构建主机上运行。但是，跨包为目标体系结构生成输出。因此校验和需要排除WORKDIR。排除工作目录的简单方法是将WORKDIR设置为某个固定值，并为“run”脚本创建校验和。另一个问题来自“run”脚本，这些脚本包含可能被调用或可能未被调用的函数。增量构建解决方案包含用于计算shell函数之间依赖关系的代码。这段代码用于将“run”脚本缩减到最小值集，从而缓解了这个问题，并使“run”脚本更具可读性。

到目前为止，shell脚本的解决方案已经存在。Python任务呢？即使这些任务比较困难，也可以采用同样的方法。这个过程需要弄清楚Python函数访问的变量以及它调用的函数。同样，增量构建解决方案包含的代码首先确定变量和函数的依赖关系，然后为用作任务输入的数据创建校验和。

像WORKDIR 的例子一样，存在依赖关系应该被忽略的情况。对于这些情况，可以使用如下行指示生成过程忽略依赖项：

PACKAGE_ARCHS[vardepsexclude] = "MACHINE"           

此示例确保PACKAGE_ARCHS 变量不依赖于MACHINE的值，即使它引用了MACHINE的值。

同样，在某些情况下，您需要添加BitBake无法找到的依赖项。您可以使用以下行来完成此操作：

PACKAGE_ARCHS[vardeps] = "MACHINE"

这个例子显式地添加MACHINE 变量作为PACKAGE_ARCHS的依赖项。

作为一个例子，考虑一个内嵌Python的例子，BitBake无法找出依赖关系。在调试模式下运行（即使用-DDD）时，BitBake会在发现无法确定依赖关系的内容时生成输出。

到目前为止，仅讨论对任务的直接投入。基于直接输入的信息在代码中称为“basehash”。但是，任务的间接输入问题仍然存在——已经构建并存在于Build Directory中的项目。特定任务的校验和（或签名）需要添加特定任务所依赖的所有任务的哈希值。选择要添加的依赖项是一个策略决策。然而，其效果是生成一个主校验和，它结合了basehash和任务依赖项的散列。

在代码级别上，存在多种方法可以影响basehash和依赖任务哈希。在BitBake配置文件中，可以为BitBake提供一些额外的信息，以帮助它构造basehash。下面的语句有效地生成了一个全局变量依赖排除列表（即变量从未包含在任何校验和中）：

BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
     SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
     USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
     PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
     CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"

前面的例子排除了WORKDIR ，因为该变量实际上是作为TMPDIR中的路径构造的，TMPDIR位于白名单中。

决定通过依赖链包含哪些依赖任务哈希的规则更为复杂，通常使用Python函数来完成。meta/lib/oe/sstatesig.py显示了两个示例，并说明了如何在需要时将自己的策略插入到系统中。这个文件定义了OE-Core使用的两个基本签名生成器：“OEBasic”和“OEBasicHash”。默认情况下，BitBake中启用了一个虚拟的“noop”签名处理程序。这意味着行为与以前的版本没有变化。默认情况下，OE-Core通过中的此设置使用“OEBasicHash”签名处理程序bitbake.conf文件：

BB_SIGNATURE_HANDLER ?= "OEBasicHash" 

“OEBasicHash” BB_SIGNATURE_HANDLER 与 “OEBasic” 版本相同，但将任务哈希添加到stamp文件中。这将导致更改任务哈希的任何元数据更改，从而自动导致任务再次运行。这就消除了对PR 值的需要，对元数据的更改会自动在构建中产生涟漪。

还值得注意的是，这些签名生成器的最终结果是使一些依赖项和哈希信息可用于构建。这些信息包括：

• BB_BASEHASH_task-taskname：配方中每个任务的基本哈希。
• BB_BASEHASH_filename:taskname：每个依赖任务的基哈希。
• BBHASHDEPS_filename:taskname：每个任务的任务相关性。
• BB_TASKHASH：当前正在运行的任务的哈希值。

---

3 共享状态

解决前面讨论的共享状态和半个状态的校验和问题。问题的另一半是能够在构建期间使用校验和信息，以及能够重用或重建特定组件。

sstate 类是如何“capture”给定任务的快照的相对通用的实现。其思想是构建过程不关心任务输出的来源。输出可以是新生成的，也可以从某个地方下载和解包。换句话说，构建过程不需要担心它的起源。

存在两种类型的输出。一种是在WORKDIR中创建一个目录。一个很好的例子是do_install 或do_package的输出。另一种类型的输出发生在将一组数据合并到共享目录树（如sysroot）中时。

Yocto项目团队试图将实现的细节隐藏在sstate类中。从用户的角度来看，将共享状态包装添加到任务中非常简单，这是一个取自deploy 类的do_deploy 示例：

DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
SSTATETASKS += "do_deploy"
do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"

python do_deploy_setscene () {
    sstate_setscene(d)
}
addtask do_deploy_setscene
do_deploy[dirs] = "${DEPLOYDIR} ${B}"
do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"       

下表说明了前面的示例：

• 在SSTATETASKS 中添加“do_deploy”会在do_deploy 任务之前和之后添加一些必需的sstate相关处理（在sstate 类中实现）。
• do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"声明当正常运行时（即不使用sstate缓存时），do_deploy将其输出放在${DEPLOYDIR}中。此输出将成为共享状态缓存的输入。
• do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"这一行将共享状态缓存的内容复制到${DEPLOY_DIR_IMAGE}。

注意：如果do_deploy不在共享状态缓存中，或者如果它的输入校验和（签名）与缓存输出时不同，那么任务将运行以填充共享状态缓存，然后共享状态缓存的内容将复制到${DEPLOY_DIR_IMAGE}。如果do_deploy在共享状态缓存中，并且其签名指示缓存的输出仍然有效（即如果没有相关的任务输入发生更改），则共享状态缓存的内容将直接由do_deploy_setscene 任务复制到${DEPLOY_DIR_IMAGE}，而跳过do_deploy 任务。

• 以下任务定义是使先前设置生效所需的粘合逻辑：

python do_deploy_setscene () {
     sstate_setscene(d)
}
addtask do_deploy_setscene           

sstate_setscene()将上述标志作为输入，并通过共享状态缓存加速do_deploy 任务（如果可能）。如果任务被加速，sstate_setscene()将返回True。否则，它将返回False，并运行正常的do_deploy 任务。

• do_deploy[dirs] = "${DEPLOYDIR} ${B}"这一行在do_deploy 任务运行之前创建${DEPLOYDIR}和${B}，并且还将do_deploy 的当前工作目录设置为${B}。

注意：在sstate-inputdirs和sstate-outputdirs相同的情况下，可以使用sstate-plaindirs。例如，要保留do_package 任务的${PKGD}和${PKGDEST}输出，请使用以下命令：

• do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"这一行将额外的元数据附加到stamp文件中。在这种情况下，元数据使任务特定于机器的体系结构。
• sstate-inputdirs和sstate-outputdirs也可以用于多个目录。例如，以下命令将PKGDESTWORK 和SHLIBWORK 声明为共享状态输入目录（填充共享状态缓存），将PKGDATA_DIR 和SHLIBSDIR 声明为相应的共享状态输出目录：

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数嵌入式工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年嵌入式&物联网开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上嵌入式&物联网开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以+V：Vip1104z获取！！！ （备注：嵌入式）

最后

资料整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~

你的支持，我的动力；祝各位前程似锦，offer不断，步步高升！！！

sdnimg.cn/images/73bb5de17851459088c6af944156ee24.jpg" alt=“img” style=“zoom: 67%;” />

最后

资料整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~

你的支持，我的动力；祝各位前程似锦，offer不断，步步高升！！！

更多资料点击此处获qu！！