okumoto at ucsd.edu
Wed Jan 12 10:41:54 PST 2005
Zera William Holladay wrote:
I've been reading the "Design and Implementation of the 4.4 BSD Operating
System." I have a few questions concerning system calls on DFBSD and in
general. For reference, I have been looking at pg. 53, chaper 3.2.
I'll start by summarizing what is written: a system call handler must 1.
veryify that parameters are at a valid user address space and 2. call a
kernel routine that implements the system call.
So my questions are:
1. What is the diff between a "trap" and an "interrupt?" The distinction
between the two seems blurred at best.
I usually define them this way.
Interrups are async, they happen when things external to the code
stream change the flow of execution.
traps are synchronis, they occur because of something in the code
stream. (for example you dereference NULL, divide by zero, etc)
Unix signals are a union of both of the above.
The problem is that many people use the word trap the same as signals.
So you run into the confusion you are having.
2. What is a trap into the kernel? How does this work? Where is the C
code in the /usr/src?
> 3. What is the system call handler? Is the system call handler any
> different from a signal handler in a user process? How does the
system call handler locate the address of the kernel routine?
All CPUs have a exception table that gets referenced when some event is
supposed to change the stream of execution.
Some those events are:
o Divide by zero
o Invalid memory reference
o Hardware interrupt (clock, reset button, disk, etc.)
o trap instruction.
You can find this code in /usr/src/sys/i386/i386/exception.s
Each of those slots in the exception table point to code that
handles that type of event. In the case of a system call,
the standard lib contains wrapper functions that invoke a
special instruction which generates a trap (int 0x8).
When the CPU sees this instruction it saves the current
state of the registers, possiblely changes the memory
mappings (make kernel code and data visiable) and invokes
the code in the (int 0x8) handler. So your code does not
need to know the location of the kernel routine. After
the kernel is done, it puts the memory mappings back the
why they were before and puts most of the register back.
(note: using (int 0x8) is just convention, there are other
trap instructions. In theory you could use any instruction
that causes the CPU to reference the excpetion table even
the seg fault vector.)
The authors state that the most frequent traps into the kernel are system
calls (after clock processing). I assume the code concerning the above
must be very fast and machine specific. If this is not the appropriate
list to ask these questions, then I apologize.
More information about the Kernel