Magenta是按照微内核的思路打造的，但不同于学院派的微内核，看上去没那么美，走的是一条实用化的道路。
本想自己写点东西，但magenta自带的文档已经挺完善，以下的内容的一部分来自对文档的引用。

---

Magenta - 概述

---

基于微内核的特性，Magenta只负责管理如下资源：

• scheduler,继承自LK并增强；
• 中断,处理（一部分，另一部分可在user space处理）
• memory space
• Handles，句柄管理
• object，对象管理

其他关键的的OS元素，比如文件系统、驱动等等，在user space实现。
有些微内核只负责schedule和object管理，从这点看，magenta并不那么纯粹。

Magenta是基于object的kernel，将各种资源以object的方式组织，并以Handle的方式提供给user。user从而可以通过Handle访问并操作object；kernel负责object的生命周期管理。

下图是用户句柄、kernel句柄和object的关系的一个简单表示。

                 | handle
user-space       |
------------------------------ sys-call
kernel-space     |
                +++
                 +                
             ==========
             | Handle |
             ==========
                 |
                +++
                 +
             ==========
             | Object |
             ==========

---

user handle

---

定义为

typedef int32_t mx_handle_t;

可见是32bit的整形变量。代表在process中，对kernel Handle 的索引。
user handle只在本process内有效。同样的user handle value，在其他process中，或指向另一个object，或就是无效的索引。

---

kernel Handle

---

定义为

class Handle final : public mxtl::DoublyLinkedListable<Handle*> {
        。。。
}

在kernel中，接收到user handle后，将此32bit的变量移位、计算后，可得到Handle一个实例的基地址，从而可得到一个Handle。可见user handle和kernel Handle是一一对应的。

Handle中保存着如下成员：

* dispatcher_, 指向object的指针
* rights_, 访问object所需权限
* process_id_, 所属process的ID
* base_value_, 本Handle的基地址

kernel会检查当前process是否有权限可以访问此Handle；是否有权限可以访问此Handle指向的Object。

不是所有的kernel Handle，对user都是可见的。当kernel Handle处于in-transit状态时，此Handle对user不可见。此种情况一般发生在handle转移时。举例如下：

• 当A process想将1个Handle 传递给B process，A process调用 mx_channel_write , 并以1个user handle为参数。
• kernel接收到此handle后，将其转换为kernel Handle， 将 process_id_ 赋值为0，表示此Handle和kernel绑定，不在属于A Process， 处于in-transit状态；最后将Handle从A Process的Handle space中去除。此时此Handle对A process和B Process的user都是不可见的。
• B Process调用 mx_channel_read 后，kernel会将此Handle映射至B Process的Handle space，且process_id_ 重新赋值为B Process的ID。此时，此handle对B Process的user可见。
• 如果在B Process调用mx_channel_read 之前， A Process就关闭了此channel，则此Handle也自动关闭。

---

Object

---

Object在实现上，都会继承Class Dispatcher，从而所有的object实例都有统一的header。此header记录object的ID、被Handle引用的次数、object类型、object name等等。利用Handle得到object后，可从header查询到object的info，从而可以判断Handle是否是合法的访问此object。

object本身是不带任何security信息的，即默认可以被任意访问。 user的访问权限，是在Handle中做的检查。一个进程的2个带不同的权限的Handle是可以指向同一个object。

object的生命周期和其被引用的次数有关。当object被创建时，有1个Handle指向此object，则其被引用次数为1； 当后期有其他Handle也指向此object，则其被引用次数+1。当Handle被关闭时，object的被引用次数-1；当被引用次数达到0时，此object自动被释放。

当1个Handle有效时，其指向的object也肯定有效；而当Handle关闭时，其指向的object不一定也被关闭，因为其他Handle或kernel code仍在引用此object。

Magenta是围绕着object运转的，object可分为2大类：面向App和面向driver。

面向App的object

1/ 用于执行code

* Job
* Process
* Thread
* Task

Thread属于Process；Process属于Job。而Task是对3者的统称。在user可使用Task相关的sys-call控制Thread/Process/Job。

2/ 用于传递消息和数据

* Socket
* Channel
* Fifo

3/ 事件通知

* Event
* Event pair
* Futext

4/ Waiting

* WaitSet
* Port

5/ 虚拟内存管理

* VMO， Virtual Memory Object
* VMAR，Virtual Memory Address Region

面向driver的object

* Interrupt request
* Resource
* Log

---

Devmgr和Devhost

---

如果magenta只有1个裸核的话，那毫无用处。完整的系统，缺一不可。所以在user space实现了设备管理(Devmgr)和驱动管理（Devhost)。

下一次从userboot开始讲起。