テキストの36ページ
我々は前節で、どのハンドラもトラップフレームをセットアップし、そしてCの関数であるtrapを呼ぶところを見てきた。
trap関数は、なぜ呼ばれ何をすべきか決定するためにハードウェアトラップ番号tf->trapnoを見る。
もしそのトラップがT_SYSCALLなら、trap関数はシステムコールのハンドラであるsyscall関数を呼ぶ。
我々は、第4章で2つのproc->killed(原文ではcp->killedになってるけど多分間違い)について再検討する予定である。
trap.cのtrap関数
void
trap(struct trapframe *tf)
{
if(tf->trapno == T_SYSCALL){
if(proc->killed)
exit();
proc->tf = tf;
syscall();
if(proc->killed)
exit();
return;
}
switch(tf->trapno){
case T_IRQ0 + IRQ_TIMER:
if(cpu->id == 0){
acquire(&tickslock);
ticks++;
wakeup(&ticks);
release(&tickslock);
}
lapiceoi();
break;
case T_IRQ0 + IRQ_IDE:
ideintr();
lapiceoi();
break;
case T_IRQ0 + IRQ_IDE+1:
// Bochs generates spurious IDE1 interrupts.
break;
case T_IRQ0 + IRQ_KBD:
kbdintr();
lapiceoi();
break;
case T_IRQ0 + IRQ_COM1:
uartintr();
lapiceoi();
break;
case T_IRQ0 + 7:
case T_IRQ0 + IRQ_SPURIOUS:
cprintf("cpu%d: spurious interrupt at %x:%x\n",
cpu->id, tf->cs, tf->eip);
lapiceoi();
break;
//PAGEBREAK: 13
default:
if(proc == 0 || (tf->cs&3) == 0){
// In kernel, it must be our mistake.
cprintf("unexpected trap %d from cpu %d eip %x (cr2=0x%x)\n",
tf->trapno, cpu->id, tf->eip, rcr2());
panic("trap");
}
// In user space, assume process misbehaved.
cprintf("pid %d %s: trap %d err %d on cpu %d "
"eip 0x%x addr 0x%x--kill proc\n",
proc->pid, proc->name, tf->trapno, tf->err, cpu->id, tf->eip,
rcr2());
proc->killed = 1;
}
// Force process exit if it has been killed and is in user space.
// (If it is still executing in the kernel, let it keep running
// until it gets to the regular system call return.)
if(proc && proc->killed && (tf->cs&3) == DPL_USER)
exit();
// Force process to give up CPU on clock tick.
// If interrupts were on while locks held, would need to check nlock.
if(proc && proc->state == RUNNING && tf->trapno == T_IRQ0+IRQ_TIMER)
yield();
// Check if the process has been killed since we yielded
if(proc && proc->killed && (tf->cs&3) == DPL_USER)
exit();
}
システムコールの為のチェックの後、trap関数はハードウェア割り込みを見る。(これについては後で説明する。)
予期されたハードウェアデバイスに加えて、trap関数は擬似割り込み(不必要なハードウェア割り込み)によっても引き起こされる。
もしトラップがシステムコールやハードウェアデバイスの割り込みでなければ、trap関数はそれをトラップの前に実行されてたコードの一部によるおかしな処理(例えばゼロ除算)によって引き起こされたものだと仮定する。
もし、そのトラップを引き起こしたコードがユーザプログラムなら、xv6は詳細を印字し、そしてそのユーザプロセスをクリーンアップする事を忘れないようにするためにproc->killed(原文ではcp->killed)をセットする。
我々は、第4章でxv6がどうやってこのクリーンアップを実行するかを見る予定である。
もし、それがカーネルの実行中なら、カーネルのバグということになる。
trap関数は、その驚きについて詳細を印字し、そしてpanic関数を呼ぶ。
trap関数ではtf->trapnoで処理を割り振るという話です。
cp->killedとproc->killedについては、gitのログを調べたところ2009/8/31にrename c/cp to cpu/procというコメントを含んだコミットがありそこでcpからprocに変更されていたので、本文が間違ってる(古いまま残ってる)のだろうと思います。
最近のコメント
たかたむ
はじめまして。初リアルフォース(R3ですが)で,同…
nokiyameego
ZFS poolのデバイスラベル破損で悩んていたと…
名前
しゅごい
Jane Doe
FYI Avoid Annoying Unexpe…
Jane Doe
ご存じとは思いますが、whileには、”~の間”と…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…