CS644

Change your text as follows to clarify some confusing language

Pg. 54, caption to Figure is unclear:
Transition from sleeping to running has 2 parts:
1. Call to try_to_wake_up that sets task to TASK_RUNNING and adds it to a 
runqueue
2. Something else calls schedule() a little while later, which finds it on 
the runqueue and schedules it.
Thus wake_up can be called from softirqs, which may not themselves 
call schedule().  It is commonly called from interrupt handlers.

On pg. 57, below the two bullets:

If it called schedule() only when code explicitly did so
--change: add syscall--
If it called schedule() only when *syscall* code explicitly did so

Discussion:
Obviously *any* call to schedule is coded explicitly somewhere.  The sense 
here is that obvious calls, ones in syscall code (or more generally calls
executed in process context) to schedule, are not enough to stop a runaway
user process, since it can execute without calling any system calls.

Pg. 57 below the bullets "when a process runs out of timeslice"
Note that this occurs in the timer interrupt handler.

On pg. 59, in the middle of the page:
Discussion: A "preemption" is a loss of the CPU when the current activity could
still use it, so blocking is not really preemption.  For some reason, Love
is calling it "explicit kernel preemption" here, which I think is confusing.

Quote from Love:
Kernel preemption can also occur explicitly, when a task in the kernel blocks 
or calls schedule().
--change to--
The kernel execution in process context can also lose the CPU for that 
process (i.e. reschedule it), when a process in the kernel blocks or calls 
schedule().

pg. 59, above the bullets:

Kernel preemption can occur
--change to--
While running in process context, the kernel can reschedule the current 
process

The first two bullets list the preemption cases.
The last two bullets list the non-preemptive cases.

Discussion for pg. 59:
"kernel preemption" means loss of the CPU for the process by means other than 
explicit calls to schedule in process context code, usually because of an 
interrupt occuring between the instructions of the process context code 
(or because of an unlock done by the code that makes the code preemptible 
again).  This is the meaning of the preempt_count > 0 condition.

Pg. 83: Note that this example is not a typical interrupt handler because
it runs SA_INTERRUPT (IF=0), and shares data with other interrupt
handlers rather than the usual sharing of data with softirq or process
context executions.  But at least it shows direct interaction with
hardware: The CMOS_READ macro expands to an outb to port 0x70 and an inb
from port 0x71.

S10: ignore the next two comments: we didn't cover bottom halves

pg. 84, just after Interrupt Context title:
When executing in interrupt handler or bottom half, the kernel is in 
interrupt context.  It should say bottom half other than work queue.

pg. 91: middle of page
in_interrupt(): in interrupt context, i.e., in top half, softirq, or 
tasklet on this CPU, but this does not include work queue context, 
which is process context even though it is a bottom half handler.

pg. 125: "synchronizing with user space" Reading or writing to user memory 
can cause page faults, which require a sleep to handle. 

pg. 125, line 8
Likewise, it is a bug if code in the kernel sleeps while in the middle of a 
critical section.  True for spinlocks, but not for kernel semaphores, which 
allow blocking (when absolutely needed.)  See pg. 144.