Magenta

Fuchsia的核心是Magenta microkernel，它负责管理硬件，并为系统的使用者空间组件提供抽象层，类似于Linux对GNU等项目的支持。而Magenta建立的基础——Little Kernel则是Fuchasic的开发者Travis Geiselbrecht在加入谷歌前所研发的一个项目。LK的目标是要建立一个能够运行在有限资源的微型嵌入式系统（类似于FreeRTOS或ThreadX）之上的小型内核，而Magenta则是针对更复杂些的硬件——想要允许的话，需要至少64 bit的CPU，配以一块内存管理单元。因此，Magenta在LK的有限功能上进行了扩展，它使用了LK的“内部构造”，包含线程、互斥锁、计时器、事件（信号）、等待队列、信号及虚拟内存管理器（VMM）。在Magenta中，LK原本使用的VMM已经有了实质提升。

Magenta的一个关键设计在于运用了capability，这是一个计算机科学的抽象概念，封装了访问某个对象的权限。这一概念是1966年由Dennis和Van Horn首次提出的（点击这里查看原PDF），指的是一个不可伪造的数据结构，在操作系统中担任控制访问权限的基元。在Magenta中，开发人员使用了capability的模型，以定义某个进程与内核、与其他进程的互动方式。

具体实现中，Magenta采用了名为handle的构造，只要有进程请求创建内核对象，就会自动生成handle，用于处理与该内核对象的“会话”，几乎所有系统调用都需要通过handle来实现。handle包含与其相关的权限，也就是说它们定义了在使用时允许哪些操作。此外，handle可以通过进程复制或转移。可授予handle的权限包括读写相关核心对象的权限，只要是虚拟内存对象即可，无论能否被映射为可执行对象。对于沙盒中的特殊进程来说，handle非常有用。因为经过调整，handle可以设置为仅允许对系统的某个子集可见、可访问。

由于我们将内存作为可通过核心对象访问的资源，各个进程可通过handle来获得对内存的应用。在Fuchsia中创建进程，代表着一个负责创建的进程（比如shell）必须手动为子进程完成创建虚拟内存对象的工作——这一点与传统不同：在传统的Unix类内核，比如Linux中，内核会完成大部分的虚拟内存设置，自动处理进程。Magenta的虚拟内存对象可通过多种方式来映射内存，而且在进程执行中灵活性很高。甚至可以想象完全不对内存做映射的场景，在此场景下，通过类似文件描述符之类的handle，也可以对系统进行读写。尽管这种设置允许任何类型的创造性使用，这也意味着想要运行进程，需要通过使用者空间的环境完成许多的基础架构工作。

由于Magenta是按照微内核来设计的，操作系统的大多主要功能组件也是当作使用者空间进程来运行的，其中包含驱动程序、网络堆栈以及文件系统。最初从IwIP引导的网络堆栈最终被Fuchsia团队所编写的用户网络堆栈所取代。网络堆栈是一个中间性应用，简于使用者空间的网络驱动，以及需要网络服务的应用之间，通过网络堆栈，系统提供了一个BSD socket API。

默认的Fuchsia文件系统被称为minfs，也是从零开发的。驱动管理器创建了根文件系统内存，为其它安装在下面的文件系统提供虚拟文件系统层（VFS）。然而，由于文件系统是作为使用者空间的服务器来运行的，需通过服务器的相应协议来访问。文件系统中的各个实例都包含后台运行的服务器，以处理所有的数据访问。借助使用者空间的C library，对于只进行调用以开关、读写文件的用户程序来说，协议都是透明的。

Fuchsia的图形驱动程序也作为使用者空间的服务存在，按照逻辑分为系统驱动以及应用驱动。两者之间促进沟通的软件层被称为Magma，是一个提供合成与缓冲区共享的框架。绘图堆栈的某部分即Escher，这是一个基于物理的渲染器，通过Vulkan来提供渲染API。

完整的POSIX兼容并非Fuchsia项目的目标，足够的POSIX兼容性可通过C library来提供，C库也是musl项目连接Fuchsia的端口。这样一来，将Linux程序移植到Fuchsia系统会比较方便，但本身运行在Linux平台上的复杂程序自然需要更多的工作。