随着预算的减少、产品生命周期的缩短以及更多的功能被集成到电子设备中,开发人员感受到了交付高级软件的压力。虽然 Linux 和开源通常是嵌入式开发的正确选择,但它们不能发挥神奇的作用。一些成本仍然与选择开源开发工具相关。在决定使用哪些工具时,开发人员必须考虑他们是否将时间花在真正具有创新性和差异化的东西上,还是花在诸如集成和支持之类的繁忙工作上。
工具选择可以帮助或阻碍开发人员获得项目控制权的努力。真正有价值的工具的试金石是它们是否可以帮助开发人员在产品的短暂生命周期内启用正确的功能。
遭受这种失控的嵌入式 Linux 开发的一个领域是构建 Linux 所依赖的通常复杂的文件系统的过程。平台开发人员需要集成和安装数十个甚至数百个独立的软件组件,但手动创建目标文件系统既耗时、困难又复杂。如果没有合适的工具,这个过程很容易出错。这些时间和精力可以更好地用于开发使产品与竞争对手区分开来的功能。Linux 文件系统配置是最困难且在某种意义上回报最少的活动。
传统Linux开发
Linux 的第一个版本是在目标位于主机本身或类似机器上的环境中开发的。正因为如此,伴随的工具传统上是针对主机开发环境量身定制的。从根本上说,开发人员更容易为与他们正在开发的机器类似的机器进行开发。随着目标环境离宿主环境越来越远,开发者面临的挑战也越来越大。
为主机或类似环境进行开发不需要太多额外的工作。事实上,一些嵌入式系统与 PC 非常相似,开发人员可以运行他们选择的实际 Linux 发行版,例如 SuSe 或 Fedora。但是,针对当今市场上的一种不同处理器架构进行开发可能是一项挑战。
嵌入式Linux开发和交叉开发
当资源受到限制并且目标处理器正在运行许多可用的非 x86 处理器之一时,环境会变得更加复杂。在这种环境中,在具有许多资源的主机上进行开发,然后交叉编译为特定处理器架构开发二进制文件会更有效率。
由于其模块化设计,Linux 可以在小型设备上高效运行。开发人员可以选择他们想要实现的功能并删除他们不需要的功能。完成此任务并微调特定设备的功能和用户界面需要真正的技巧。
但仅仅因为它是模块化的,并不意味着有一条明确的成功之路。开发人员必须考虑两种方法:遵循基于包的安装,利用大多数可用的 Linux 发行版,或者将包集成到构建系统环境中。构建系统的一个问题是它与 Linux 的分发方式不一致,通常是像 .deb 或 .rpm 这样的包。另一个挑战是任何特定构建系统所需的学习曲线。以下讨论将介绍包管理器并解释它们如何帮助或损害开发人员构建嵌入式 Linux 文件系统的能力。
选择嵌入式 Linux 文件系统管理器
Debian GNU/Linux 发行版的创始人 Ian Murdock 将包管理描述为“Linux 为行业带来的最大进步。”他认为包管理模糊了 *** 作系统 (OS) 和应用程序之间的界限,使其“更容易”推动新的创新,“Ķ进入市场”,“Ķ和发展 *** 作系统。”,Äù
可用于构建嵌入式 Linux 文件系统的工具在跨平台和资源受限的环境中变得更加有用。开发人员在选择特定工具或集成开发环境 (IDE) 之前提出几个问题非常重要。考虑一下:您从哪里获得 Linux 源代码,以及它是如何打包交付的?您将文件系统用于什么目的,如何针对特定目标对其进行优化?开发人员选择的软件包安装程序可以在优化的文件系统和嵌入式设备的糟糕借口之间产生差异。
管理嵌入式 Linux 文件系统的常用方法是使用 RPM 或 dpkg 之类的包管理器来安装和删除非 root 目录,使用 fakeroot 来执行不需要 root 权限的 chroot 的偷偷摸摸的方式,或者使用虚拟目标进行开发,例如Linux QEMU 处理器仿真器或 Virtutech,Äôs Simics 虚拟平台。这些不同的选项中的每一个都有优点和缺点,可以通过替代解决方案来弥补:平台图像构建器。
包管理器
文件系统管理的卫冕冠军是 RPM 包管理器。RPM 很有用,因为它是标准的并且在大多数 Linux 系统上都可用。与其他同类产品一样,RPM 具有安装到非系统根目录的内置功能,这是有利的,因为聪明的开发人员不希望意外破坏其主机文件系统的能力。但是 RPM 并没有解决包依赖问题;它只是确定是否满足依赖关系。它要求开发人员已经知道依赖关系,因此不会去检查各种包以确定需要解析哪些包来构建文件系统。
要解决依赖关系,开发人员必须添加另一个工具,例如 Yellowdog Updater (yum) 或 Advanced Packaging Tool (apt)。作为一个 C++ 函数库,创建 apt 是为了在升级期间处理依赖关系和处理配置文件时有效地安装包。但是,apt 和 yum 仅限于命令行。如果开发人员不熟悉 Linux 或这些工具,他们可能会面临相对陡峭的学习曲线。此外,所有信息都是文本的,并且相对于图形文件系统管理器通常难以导航。
伪装根
Linux 可以适当地设置权限,以保护系统免受与修改或删除文件相关的恶意意图、无知或健忘。Linux 有一个包含所有子目录的基本根目录。这个基本根,通常称为 ‚Äú/‚Äù(发音为斜线),受到 Linux 系统用户的保护。管理员限制对“Äú/”Äù 的访问,并在其下为每个用户提供可修改的主子目录。这使用户能够访问系统并以适当的权限和能力完成他们的任务。
但是,某些文件系统创建 *** 作需要 root 权限。如果没有 root 权限,开发人员无法创建其他用户拥有的文件、创建设备节点或提交更改 root *** 作。这些限制限制了配置文件系统的能力。
一种选择是使用像 fakeroot 这样的工具,它可以在用户主机系统的目录中创建一个虚拟的“Äú/”文件系统树。它通过重新定义主机系统库中的标准函数来提供一个假的“Äú/”Äù 环境。通过这种方式,它更改了引用文件的实用程序并捕获有关文件的特权信息,而无需 root 特权来创建它们。此外,它可以与标准实用程序一起使用,而无需特殊工具。与 RPM 一样,fakeroot 不解决依赖关系,将这项艰巨的任务留给了开发人员。
在这里,RPM 和 fakeroot 都面临一个额外的挑战:开发人员可能希望在目标目录中执行代码,如果该代码用于与主机不同的体系结构,它根本不会运行。
虚拟开发
构建文件系统的第三种替代方法是使用虚拟环境,如 QEMU、Simics 或 VMware WorkstaTIon。这解决了包管理器和 fakeroot 工具都面临的挑战,即无法在与目标架构不同的主机上运行代码。虚拟环境还提供了使用主机上所有可用资源(例如内存、存储和快速处理器)为虚拟目标进行开发的能力,享受 PC 上自托管开发的许多优势。
使用虚拟环境通常比在目标本身上进行开发要快,但它会增加复杂性,相对于交叉开发降低处理器能力。
平台镜像生成器
如本文开头所述,平台开发人员需要集成和安装数十个(如果不是数百个)单独的软件组件,但手动创建目标文件系统既耗时、困难又复杂。创建文件系统后,必须将其转换为目标图像(参见侧栏)。更高级的工具可以简化组装、调整和创建文件系统映像的任务。
平台映像生成器通过提供系统的可视化地图来实现这一点,用于选择 Linux 目标包、集成自定义包和内核、动态确定文件系统大小、自动解决依赖关系和冲突,以及生成多种标准格式的文件系统。
平台图像构建器对于从最终图像中修剪组件很有用,无论它们是单个文件还是整个层次结构(例如,文档和示例配置文件)。能够将包明显地分类为文档、字体、图形或解释器等组,可以让开发人员快速访问和更快地消除不必要的包(参见图 1)。
图1
此功能还使用户能够通过树层次结构对文件和目录进行下钻和排序。要删除文件,只需取消选中相邻的框(图 2)。除了删除单个文件外,开发人员还可以选择将整个所需的支持包标记为“äúphantom”。Äù 这样的包是构建其他包所必需的,但不是最终构建所必需的,因此在运行时不包括在内。
图 2
在设置平台映像项目 (.pib) 时,开发人员可以包含和集成自定义包和内核。这种灵活性提供了竞争差异化和控制嵌入式开发人员在如此快节奏的市场中的需求。
平台映像生成器提供了许多影响映像文件大小的选项。它通过以下方式做到这一点:
优化库占用空间并减小一些共享库的大小
预链接可执行文件,加快启动速度
从最终的二进制文件中删除调试符号,使它们更小更快
这些措施不仅是为了减小图像的大小,而且是为了提高性能。
平台映像生成器使用 RPM 包中包含的依赖信息来根据需要自动包含支持包(图 3)。这与 Linux 通常的分发方式是一致的,并且消除了手动计算依赖项的平凡任务。但是,在进行包选择时,可以选择相互冲突的包。由于这会导致错误并阻止项目成功构建,因此开发人员必须在创建映像之前解决冲突。平台映像生成器通过将所有冲突标记和列出为错误来提供帮助,从而可以轻松查看和更改它们,直到所有冲突都被消除。
图 3
最后,借助平台镜像生成器等文件系统管理工具,平台开发人员可以生成常用的文件格式,包括 ext2、JFFS2、cpio、CRAMFS 和 ext3。根据格式,可以使用不同的选项来配置映像和设置挂载点。
与前面提到的为嵌入式 Linux 开发创建和管理文件系统的方法相比,平台映像生成器具有图形用户界面,不需要模拟环境,因此不会使用与虚拟机相关的资源。平台映像生成器将文件系统转换为映像,没有复杂性和较慢的处理能力,为开发人员提供嵌入式 Linux 交叉开发项目所需的生产力。
工具试金石
嵌入式 Linux 开发人员可以使用平台映像生成器等工具获得对构建复杂文件系统的更多控制,这使得组装、调整和创建文件系统映像更容易完成。这使开发人员能够花时间开发使产品与竞争对手区分开来的功能。请记住,真正有价值的工具的试金石是它们是否可以帮助开发人员在产品的短生命周期内启用更多正确的功能。
关于作者:
Troy Kitch 是位于加利福尼亚州圣克拉拉的 MontaVista Software 开发工具团队的高级产品经理。Troy 在开发和安全软件行业工作了十多年,专注于开发人员的生产力、数据存储和灾难恢复。在 MontaVista,Troy 负责通过管理 MontaVista DevRocket 集成开发环境来帮助组织充分利用开源。Troy 在圣路易斯奥比斯波的加州理工学院获得农业综合企业学士学位。
Joe Green 是 MontaVista Software 开发工具团队的经理。Joe 已经在 MontaVista Software、IBM 和 SGI 等公司使用 Linux 和 UNIX 系统工作了 20 年,并且从 0.12 版开始就愉快地使用 Linux。他特别喜欢内核和图形代码以及实时和嵌入式系统。他拥有迈阿密大学的电子工程学士学位。
审核编辑:郭婷
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)