Many functions in the kernel take a "struct proc *" as argument. When
reviewing diffs or reading the signature of such functions it is not
clear if this pointer can be any thread or if it is, like in many cases,
pointing to `curproc'.
This distinction matters when it comes to reading/writing members of
this "struct proc" and that's why a growing number of functions start
with the following idiom:
KASSERT(p == curproc);
This is verbose and redundant, so I suggested to always use `curproc'
and stop passing a "struct proc *" as argument when a function isn't
meant to modify any thread. claudio@ raised a concern of performance
claiming that `curproc' isn't always cheap. Is it still true? Does
the KASSERT()s make us pay the cost anyhow?
If that's the case can we adopt a convention to help review functions
that take a "struct proc *" but only mean `curproc'? What about naming
this parameter `curp' instead of `p'?
