稳定的内核驱动接口
Google想设计一套稳定的驱动API接口。因为Linux目前不具备这个稳定的内核内部API接口。（Linux内核的外部接口，即system call是稳定的。）所有的驱动必须放到内核里面随着大部队一起被维护。但是问题在于各种移动设备的BSP驱动太多太零碎了，而且过时的很快。内核带着这些垃圾往前走非常麻烦。
Fuchsia希望提供这样一个稳定的驱动接口，让各个厂商根据这个接口自行开发和维护驱动。
进程沙箱
Fuchsia没有传统的“根文件系统”的概念。
在Fuchsia中，路径只是一个形式上的字符串，并不一定对应于磁盘上的一个vnode。在一个进程创建时，会给它提供各种资源，这些资源被赋予各种路径。实际上，我们不应该再把这些资源的路径看成是一个统一的文件系统。路径只是这些资源的标签。进程会有一个表，用来存储从标签（即路径字符串）到资源对象句柄的映射关系。
https://github.com/fuchsia-mirror/docs/blob/master/the-book/namespaces.md
有了这样的机制，一个进程在创建时的沙箱可以用任意的方式组装起来。这个组装是必须的，因为进程一开始能访问的资源集合是空的。
一个组装例子：/pkg指向应用组件本身所在的存储区域，可以是一个merkle tree，保证程序不会被篡改。/data指向应用自己的持久存储磁盘文件系统区。/tmp指向临时文件所在的内存文件系统区。
访问控制
在Fuchsia中，不存在ambient authority. 所有的访问权限需要通过object handle获得。比如说，进程拿到了一个目录的handle，那么它才能访问这个目录下面的文件。这些句柄是在创建进程时赋予的。
在传统的操作系统中（包括Windows和Unix），授权是作为一种访问控制机制存在于系统中。在Fuchsia中，授权是作为一种实际的可传递的值（即handle）存在的。
微内核
Fuchsia是纯粹的微内核。内核中主要的抽象只包括进程、虚拟内存和IPC机制。各种文件系统、设备驱动、服务都作为一个进程跑在用户态。
这样的话，读写文件就变成了先跟文件系统进程建立一个channel，然后来回发送消息。一切都天然是异步的。
前景
微软曾经做过一次操作系统方面的全新尝试：Midori项目。2015年时管理层解散了Midori团队。大致的原因有几个：Windows团队的不接受；移植全部Windows功能代价不可接受等等。
但是Fuchsia系统对于Google来说是一个战略性的项目。因为谷歌并没有完全被自己控制的操作系统。Android和Chrome OS的底层都是Linux kernel。Linux kernel社区对于Google来说是不可控的。Google想干点啥经常被拒绝。
而且，由于Fuchsia的内核抽象非常小，完全有可能通过用户空间的抽象层兼容目前的Android, Linux上面的应用。
附：空余时间读了一点Zircon的源码，写了一点笔记贴在这里。不定期更新。
