>> sometimes a code segment may be used by both ISR or normal kernel
>> code.  ISR doesnt live in user context, so cannot block or sleep.
> neither the interrupt service routine nor rest of driver code is in
> user mode.

"in user context" != "in user mode".  The former means, more or less,
"has a process in curproc and can do per-process things like block for
resources".

>> Is there any way to detect if the code is running in interrupt, even
>> in a archtect dependent way, such as, cpu register?
> when executing within an interrupt, there is no per-process kernel
> stack and you cannot call yield to another process or sleep

This isn't a way to tell whether you're running in an interrupt, but
rather what (some of) the restrictions are when you are.

That said, I don't recall any instance when I've cared whether I'm
executing in an interrupt or not.  I much more likely want to know I
have a valid process context, or have a kernel stack, or something else
that can be tested more directly...and even those I care about only
rarely.

> curproc will most likely be set to an invalid value inside an
> interrupt service routine.

Well, "most likely" depends on your CPU load.  If you usually have a
runnable process lyign around, curproc will most likely be valid, but
usually will not bear any relation to the process (if any!) whose I/O
request you're servicing.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B