IPC
IPC是Inter-Process Communication的缩写，直译为进程间通信，说白了就是进程间发消息。我们在上一节中把这种消息传递比作邮政系统，但实际上这种比喻并不全对。有的消息机制是很像收发邮件的，这种叫做异步IPC，意思是说，发信者发完就去干别的了，收信者也一样，看看信箱里没信，也不坐在旁边傻等。而有另一种消息机制正好相反，被称为同步IPC，它不像邮寄，倒像接力赛，发送者一直等到接收者收到消息才肯放手，接收者也一样，接不到就一直等着，不干别的。
当然你可以把同步IPC也比作邮寄，只不过寄信的人从把信投到信箱里的那一刻开始，就住在邮局不走了，其他什么也不干了，就等着邮局说：“哥们儿，你的信对方已经收到了，放心回家吧！”这才恋恋不舍地离开。收信的也一样，一旦决定收信，就守在自家信箱前面不走了，一直等，连觉也不睡，望穿秋水，等信拿在手里了，这才回屋，每收一次信，就得瘦个十几斤。
我们都是性情中人，我们选择傻等，或曰同步IPC。
同步IPC有若干的好处，比如：
• 操作系统不需要另外维护缓冲区来存放正在传递的消息；
• 操作系统不需要保留一份消息副本；
• 操作系统不需要维护接收队列（发送队列还是需要的）；
• 发送者和接收者都可在任何时刻清晰且容易地知道消息是否送达；
• 从实现系统调用的角度来看，同步IPC更加合理──当使用系统调用时，我们的确需要等待内核返回结果之后再继续。
这些特性读者可能无法一下子全部明白，不要紧，我们接下来写完代码，你就全都明白了。
实现IPC
Minix的IPC机制我们已经明白了，它的核心乃在于“int SYSVEC”这个软中断以及与之对应的sys_call()这个函数。增加一个系统调用对我们来讲已是信手拈来的事，按照表7.6一步一步来就好了。我们把这个新的系统调用起名为sendrec。sendrec和sys_sendrec的函数体分别见下面两段代码：
25 sendrec:
26 mov eax, _NR_sendrec
27 mov ebx, [esp + 4] ; function
28 mov ecx, [esp + 8] ; src_dest
29 mov edx, [esp + 12] ; p_msg
30 int INT_VECTOR_SYS_CALL
31 ret
53 /*****************************************************************************
54 * sys_sendrec
55 *****************************************************************************/
56 /**
57 * <Ring 0> The core routine of system call ‘sendrec()’.
58 *
59 * @param function SEND or RECEIVE
60 * @param src_dest To/From whom the message is transferred.
61 * @param m Ptr to the MESSAGE body.
62 * @param p The caller proc.
63 *
64 * @return Zero if success.
65 *****************************************************************************/
66 PUBLIC int sys_sendrec(int function, int src_dest, MESSAGE* m, struct proc* p)
67 {
68 assert(k_reenter == 0); /* make sure we are not in ring0 */
69 assert((src_dest >= 0 && src_dest < NR_TASKS + NR_PROCS) ||
70 src_dest == ANY ||
71 src_dest == INTERRUPT);
72
73 int ret = 0;
74 int caller = proc2pid(p);
75 MESSAGE* mla = (MESSAGE*)va2la(caller, m);
76 mla->source = caller;
77
78 assert(mla->source != src_dest);
79
80 /**
81 * Actually we have the third message type: BOTH. However, it is not
82 * allowed to be passed to the kernel directly. Kernel doesn’t know
83 * it at all. It is transformed into a SEND followed by a RECEIVE
84 * by ‘send_recv()’.
85 */
86 if (function == SEND) {
87 ret = msg_send(p, src_dest, m);
88 if (ret != 0)
89 return ret;
90 }
91 else if (function == RECEIVE) {
92 ret = msg_receive(p, src_dest, m);
93 if (ret != 0)
94 return ret;
95 }
96 else {
97 panic(”{sys_sendrec}␣invalid␣function:␣”
98 ”%d␣(SEND:%d,␣RECEIVE:%d).”, function, SEND, RECEIVE);
99 }
100
101 return 0;
102 }
表7.6的最后一步中提到，如果参数个数与以前的系统调用比有所增加，则需要修改kernel.asm中的sys_call。额外要注意，我们新加的参数是通过edx这个参数传递的，而save这个函数中也用到了寄存器dx，所以我们同时需要修改save，见如下代码：
311 ; =============================================================================
312 ; save
313 ; =============================================================================
314 save:
315 pushad ; ‘.
316 push ds ; |
317 push es ; | 保存原寄存器值
318 push fs ; |
319 push gs ; /
320
321 ;; 注意，从这里开始，一直到‘mov esp, StackTop’，中间坚决不能用push/pop 指令，
322 ;; 因为当前esp 指向proc_table 里的某个位置，push 会破坏掉进程表，导致灾难性后果！
323
=> 324 mov esi, edx ; 保存edx，因为edx 里保存了系统调用的参数
325 ;（没用栈，而是用了另一个寄存器esi）
326 mov dx, ss
327 mov ds, dx
328 mov es, dx
329 mov fs, dx
330
=> 331 mov edx, esi ; 恢复edx
332
333 mov esi, esp ;esi = 进程表起始地址
334
335 inc dword [k_reenter] ;k_reenter++;
336 cmp dword [k_reenter], 0 ;if(k_reenter ==0)
337 jne .1 ;{
338 mov esp, StackTop ; mov esp, StackTop <--切换到内核栈
339 push restart ; push restart
340 jmp [esi + RETADR - P_STACKBASE] ; return;
341 .1: ;} else { 已经在内核栈，不需要再切换
342 push restart_reenter ; push restart_reenter
343 jmp [esi + RETADR - P_STACKBASE] ; return;
344 ;}
345
346
347 ; =============================================================================
348 ; sys_call
349 ; =============================================================================
350 sys_call:
351 call save
352
353 sti
354 push esi
355
356 push dword [p_proc_ready]
=> 357 push edx
358 push ecx
359 push ebx
360 call [sys_call_table + eax * 4]
=> 361 add esp, 4 * 4
362
363 pop esi
364 mov [esi + EAXREG - P_STACKBASE], eax
365 cli
366
367 ret
sys_sendrec()这个函数被设计得相当简单，它可以描述为：把SEND消息交给msg_send()处理，把RECEIVE消息交给msg_receive()处理。
msg_send()和msg_receive()这两个函数我们过一会儿细细分解，先来看看之前没出现过的assert()和panic()。这两个函数虽然起的是辅助作用，但绝对不是可有可无，因为在我们接下来要处理的消息收发中，有一些编程细节还真容易让人迷糊，这时候assert()就大显神威了，它会在错误被放大之前通知你。panic()的作用也类似，用于通知你发生了严重的错误。
