its just a case of defensive programming paranoia. i did the change after sl reported wifi kproc exiting (went into Broken) state. there seemed no other explaination other than a note interrupting it so i made all the kprocs safe to be interrupted by notes. i found this pattern in many places. most of the kprocs are just loops waiting for something and in case of error, just restart the loop. even if it is obvious that nobody is calling error() in there. (see devfloppy kproc for example). you just setup the error label at before your loop and it make it automatically restart your loop on errors. this doesnt cost you any cycles in the loop. when i see this code, i can stop worrying and assume *less* about of the surroundings.
so simply put, yes, you are right. these kprocs shouldnt get interrupted. but i made sure to catch the case anyway. i wouldnt rule out notes out of the blue. the use of postnote() is racy in many places. a Proc* pointer is not a good identifier for a process *unless* you can guaratee that the proc will not exit while you call postnote(). alarms have this race. pexit() just does up->alarm = 0; to clear alarms. if the alarm kproc was already commited posting you the note at this point (and before it got hold onto the p->debug qlock), the new process reusing your Proc* structure can get the alarm out of the blue. -- cinap
