再读syscall loop

开个syscall_loop的帖子,以后有关于syscall_loop 的新发现,都加在这里

  2011-05-12 ：

  syscall_loop (void) 函数中有下面这么一段:

/* Open Wait */
    tag = L4_Wait (&from);
    }

    if (likely(from.raw == curinfo->user_handle.raw))
    { /* 这种情况是syscall */
 curinfo->regs.mode = 1;
 curinfo->tag = tag;
    }
    else if (from.raw == L4_nilthread.raw)
    {
        /* 这种情况,是中断返回时,发送 l4_checksched*/
 curinfo->regs.mode = 1;
 /* Preemption */
 l4_work_pending_preempt(&curinfo->regs);
 goto retry;
    }

    
   上面 L4_Wait 回来,就是说main thread 又获得执行权了,也就是
   说切入kernel mode, 但是需要了解下什么原因切入的
  
   首先看下from.raw == curinfo->user_handle.raw ,为什么这个是表示
   user 发送syscall 进入kernel 的,syscall 应该是user 自己请求
   进入kernel 的, 和异常和中断不一样,他们都是被动的,那么现在判断
   下接收到的thread handle id 是否等于进入kernel前的,当前task 的
   thread handle ,如果是说明是自己主动进入,那么这个就表示是syscall
   进入内核
  
   再来看下curinfo->user_handle.raw ,这句中的user_handle, 是在
   进程创建时okl4_create_thread ,创建l4 thread 时获得的 thread handle
   为什么判断要用 thread handle ,而不是thead id ,这个是因为L4_Wait
   接收的from 是一中叫reply cap 的东西,按pdf 上所说就是
   这个reply cap 是在ipc 中用的,具体可以看下下面这段解释:
   * a reply cap can only be used once
   * a reply cap is manufactured by the kernel on-they-fly
   * a reply cap is not in any clist (and therefore doesn't occupy a clist slot)
   * a reply cap can only be used in an IPC send operation

   既然l4 kernel 这么定义,所有l4 thread 创建时,就把这个reply cap 的thread handle
   保存下来,方便以后判断
  
  
   接下是   from.raw == L4_nilthread.raw 的判断成立,我理解是对
   中断返回到svc 时(也就是svc时发生中断),进行内核抢占的情况的模拟
   在sys_iguana.c 中interrupt_loop 处理完中断最后有l4_checksched
   的调用,l4_checksched代码如下:

static void
   l4_checksched(void)
   {
 if (need_resched())
  L4_Notify(main_thread, L4_PREEMPT);
    }

   
   发从一个异步的notify给main_thread,而interrupt_loop
   是在timer_thread中,这样上面 if (likely(from.raw == curinfo->user_handle.raw))
   肯定不成立,但是为什么timer_thead 发起的l4 notify ,l4 wait 到的是nilthread呢?
   我自己的理解是,timer_thread 是l4 kernel 运行的第1个main,他仍然属于l4 kernel
   而不是创建的user l4 thread ,所以他的thread handle 是nil thread,这和interrupt_loop
   中判断nilthead发送来的interrupt notify ,才有效一样

   然后进入l4_work_pending_preempt,
   如果TIF_NEED_RESCHED ,L4_Stop_Thread停止当前thread,
   调用schedule 进行内核抢占的重新调度

2011-05-25:

   在nlinux 中 user 进kernel 对于pt_regs的建立都是在:

   .macro usr_entry (entry-arm.S) 中,构建栈

   但是在oklinux ,是通过获得user 切出执行权到oklinux kernel 然后

   oklinux kernel 中l4 wait 类api 会接收到的user 的tag,根据tag 来获得

    msg ,这个msg 就是user 的pt_regs

   在syscall_loop 函数的末尾有句:

   L4_MsgStore (curinfo->tag, &curinfo->regs.msg); /* Get the tag */

    着句就是根据tag,获得 msg,然后 通过include/asm-l4/ptrace.h 
     中相应函数去设置或者读取msg's reg

   注意这个只是user syscall 切入oklinux kernel的点,其他如user 态中断切入点,在interrupt_loop

   同样interrupt_loop中也包含return to user 的情况,syscall_loop 只包含异常和syscall

   的情况