I think you're right.
Okay; I'll fix this too. Come to think of it, kwatch needs to handle
multiple hits as well -- there might be two watchpoints set to the same
address.
It's still more complicated than you might think. Let's say two user
processes each have dr1 allocated, one with low priority and the other
with high priority. The kernel has to be aware of the high-priority
allocation, so that it can refuse intermediate-priority kwatch allocation
attempts. Now suppose the second process exits. dr1 is still allocated
to the first user process but only with low priority, so now
intermediate-priority kwatch allocation attempts should succeed.
In order for this to work, when the second process gives up its allocation
I would have to either scan though all tasks to see the first process, or
else keep several global use counts for each slot -- in fact, one use
count for each priority level. That's doable if there are only a few
levels, but not if there are many.
How do you suggest this be handled? Maybe we should just keep track of a
maximum user priority level for each slot, allowing it to go up but not
down until all user processes have given up the slot. (I.e., in the
example above the later kwatch requests would still fail because we would
continue to remember the high user priority level so long as the first
process maintained its allocation.) That would be overly pessimistic, but
it would at least be safe.
Alan Stern
-
