Wayland向非Linux架构嵌入式操作系统的移植

这个工作开始于几年前，当年基本完成。工作多年来移植了包括图形驱动、Qt、通信协议在内的不少软件，大部分与图形相关，这项工作是其中规模最大的一个，难度也相当大，一直想把思路过程归纳整理出来，因种种原因拖到现在。从今天开始抽时间，不做计划，想到哪写到哪，不做过多整理，回忆一下整个移植过程，基本说清楚即可，也希望一起回顾下其它软件移植的经验，在其中一并介绍，希望不会烂尾，也算是人老了，留个纪念。

今天开始，首先简单介绍一下Wayland、为什么要向非Linux架构嵌入式操作系统移植，并写下大概思路。

1 Wayland简介

网上介绍Wayland的文章很多，我这里为方便后续工作理解，仅作简单介绍，后面结合移植工作再适当展开。

Wayland是替代X的新一代图形协议。X是构建Unix、Linux等类Unix架构操作系统图形人机交互的基础协议，经过几十年发展，已变得臃肿不堪，基于X构建的图形性能相比Windows差距明显，Wayland应运而生。

注意，Wayland和X一样，只是图形Client与Server间的交互协议，并非图形系统。要构建完整的图形系统，还需要Weston等混成器、Mesa/FrameBuffer等显示驱动后端、Qt/cairo等图形绘制SDK，以及键盘、鼠标、显卡、显示器等硬件及对应驱动。Wayland是图形系统的核心，关系整个图形系统的性能。因此在非Linux架构嵌入式操作系统上构建基于Wayland的图形系统，还需要移植上述软件，并补齐Wayland所依赖的操作系统底层机制。

2 为什么要向非Linux架构嵌入式操作系统移植Wayland

首先，嵌入式应用对基于图形界面的人机交互要求越来越高，而很多嵌入式操作系统并无成熟的图形解决方案，即使有，也往往缺乏标准且功能不强。例如VxWorks的图形系统一直在变化，从最初的WindML/Zinc，到OpenGL，再到Tilcon、Qt，一直在摇摆，造成用户图形应用的继承性较差。Wayland作为X的替代品，已成为类Linux操作系统的新一代图形协议标准，其生态已经相对完善，且展现出强大的生命力。将其迁移到非Linux架构嵌入式系统，可极大丰富对应系统的生态，增强其适应性，降低用户图形应用开发门槛，提升用户应用的可移植性。

3 基本思路

上面提到过，Wayland的迁移涉及混成器等多个软件，移植工作量相当大，是一个系统性工程。另一方面，嵌入式操作系统通常功能相对精简，其提供的底层机制相比Linux不仅不完整，而且可能存在语义不一致的问题，需要补齐和完善待移植软件所需的支撑机制。再者，嵌入式操作系统所支持的工具链版本通常低于Linux，一些高版本C/C++的语言特性可能不支持，因此在选择Wayland及配套软件的版本时，必须考虑工具链的可支持能力。特别是构建方式，嵌入式系统通常仅支持Makefile，因此Wayland等软件要选择仍支持Makefile构建的版本。

相比Wayland、Weston等软件的移植，Mesa以及OpenGL图形驱动的移植工作量和难度更大，图形后端应优先选择帧缓冲（Framebuffer）模式的驱动。

另外，Linux下的开源软件依赖关系很复杂，构建完整图形系统所需的软件集合需要逐步明确。这些软件的Makefile可以先在Linux下生成，再在嵌入式操作系统环境下做对应修改。

今天先写到这，下次介绍我选择的版本，以及基本环境的构建。