13 Dec
2002
13 Dec
'02
6:04 a.m.
Wolfgang Helbig wondered,
While studying the V6 kernel, I search for some rules
as when to raise
the interrupt priority level (IPL). I came up with something like this:
A kernel process needs to raise the IPL if a change of data must be atomic and might
be accessed (not necessarily changed) by an IRS.
In light of this rule, some raising of interrupts seem
unnecessary:
- In m40.s changes of the user space segmentation registers are bracketed by raising
and lowering the IPL, although these registers are never accessed by an ISR.
- Likewise, in m40.s, just before the trap routine
checks the runrun flag and
restores r0, r1 and the user stackpointer, it raises the IPL. I can't see what
possibly should go wrong, if being interrupted while restoring the values.
It's quite possible that the code is unnecessarily cautious.
In general one does not want an interrupt while something
sensitive is in a half-changed state (for example, some of
the addressing registers changed, or a stack half-switched).
For example, the clock interrupt routine can inspect user
space (for display(), for example, though this is inactive
on the 11/40), and even change it (for profiling).
It does appear that other things (checking for
a direct-from user-mode interrupt) in the clock routine
already guard against these particular problems.
It's been a long time since I've looked at this, however.
Dennis