l4linux 编译,[转]L4Linux实现原理

该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

8) Linux Threads Linux可以运行多个Linux User Process(比如fork)在同一个Address Space，但是在L4Linux中，每一个L4Linux User Process都运行在一个单独的Address Space，相当于L4的一个Task。

以上8个方面是L4Linux移植过程中特别需要关注的问题，也是理解L4Linux的基础，我认为任何Linux-Like的操作系统到L4系统的移植都可以采用如上的基本策略或者其中的某几个。L4跟Linux是完全不同的两种操作系统类型，从基本概念到实现方式上面都有太多的不同，L4到Linux 的差距远远大于Minix／Unix／Partikle到Linux的差距。我的意思是说，虽然L4，Minix都是微内核，有一些基本的概念相同，如 IPC，但是其余的比如内存管理，进程调度等方面，存在太多的不同。这些方法也是从L4Linux-2.0.x，L4Linux－2.2.x, L4Linux-2.4.x到L4Linux-2.6.x所遵循的基本原则。

在上面所说的8点之中，有2个问题需要注意，其中有一个是关于Signal的问题，在V2和X.0的L4 API中，l4_thread_ex_regs是不允许修改当前Address Space之外的线程的，这给Signal的实现就带来了一点麻烦，因为不管是Signal的最终完成是需要内核的参与，都需要迫使L4Linux User Process切换到L4Linux Server去执行，在Native Linux下面，内核可以抢占用户进程，但是在L4Linux下面，如何使得一个User Process切换到另一个User Process，假如没有一个可以跨越Address Space进行线程修改的系统调用，Signal的实现只能依靠上面的那种方式，用一个单独的线程作为Signal Thread，去监听是否有新的Signal，如果有，Switch到L4Linux Server。当前，在L4Linux实现的时候，Fiasco不支持X.2API，但是对内核作了一些修改，提供了可以跨越Address Space的类l4_thread_ex_regs系统调用，l4_inter_task_ex_regs。

另一个问题是关于Exception和System Call的问题。在V2和X.0的API中，L4通过一个Thread Local Interrupt Descriptor来处理Exception和System Call，但是这些Thread Local Interrupt Descriptor实际上是L4 Kernel的一部分，L4 Kernel提供一个IDT(interrupt descriptor table),然后一旦发生系统调用，L4 Kernel会把这个IDT map到L4 Thread的地址空间，这个过程被称为“Exception Handler Installation",很显然，这个过程是需要改变privilege level的，而且需要执行一部分Exception Related的内核代码。很显然，如果我们仍然采取以前的策略，对于每一个Linux所触发的Exception或者System Call都采用L4 Kernel来处理，肯定会有较大的performance loss，这里会改进的余地。 V.2API提供了一种机制，称为"Exception IPC“， Exception IPC的本质含义就是可以把Exception Handler的代码放在用户空间，而且Exception Handler Thread可以在任意位置，一般有Exception发生，一个tagged IPC可以到以前指定的Exception Handler，IPC是synchronous,所以可以终止当前线程的执行，去执行Exception Handler，执行完毕，Exception Handler IPC返回的时候，继续执行以前的代码。这么作的好处是显而易见的，执行一个Exception或者System Call的时候，不需要切换完成真正的kernel spaceuser space的切换，虽然中间有一个IPC存在，但是L4的IPC是Fast IPC,所需时间应该远远小于privilege switch的时间。

但是在这个过程中，还有一个问题，就是我们需要从Exception Triggering Thread到Exception Handler发送一定的消息，X.2API提供了一种机制，UTCB(User Thread Control Block),用于传送Thread Control的消息从Exception Triggering Thread到Exception Handler。在这种情况下，每次只能最多传递2个参数的short IPC是不够的，需要Long IPC把UTCB搬过去。Exception IPC是目前L4Linux处理Exception, System Call以及Interrupt的一个比较有效的方式，因为a)避免在当前的Thread中包含Handler代码b)避免L4Linux Server和L4Linux User Process贡献Handler c)避免Addtional Kernel Entry。

其他的从L4Linux User Process进入L4Linux Server的方法就是Page Fault，很显然，因为Pager是L4Linux Server，所以一旦Page Fault发生，就可以迫使L4Linux User process到L4Linux Server的切换，但是一般发生Page Fault的时候，kernel只是记录发生Page Fault的地址，并不记录发生Page Fault Thread的状态，所以要通过Page Fault的方式实现Signal, Interrupt, exception的处理，就要去修改Microkerne，即对所有的Exception进行类似Page Fault的处理，这样得不偿失(Microkernel对PageFault的处理是个例外), 相对前面的方法，这种方式更为复杂。

采用Exception IPC也有一定的缺点，因为UTCB会记录当前Thread State有关的所有Register，所以对于相关Register较少的IA-32而言，这种方式较好，但是对于IA－64的很多的Register 来说，Copy所有的Register Value是一项比较费时间的工作(我不清楚IA－64和IA－32的区别，不做评论), 而且Thread State相关的Register其实不是很多，所以Copy All也是没有必要的(从这里看出来，X.2可能还会继续update，至少UTCB不是很完美)。另：在PowerPC,IA64等平台下面， Kernel Entry很快(40Cycle，约相当于)，所以是不是需要这么介意Kernel Entry的问题，本身也是个问题。但是不管怎么说，目前的L4Linux就是使用Exception IPC来解决Linux Exception问题的。