Hi,

> So then my next question is: shouldn't there be a way?

As an aside, note that there is a mechanism for the clock interrupt
handler to determine whether it was called from interrupt context.
It is solely used to eventually save a software interrupt on return
from the hardclock interrupt handler.  I'm not even sure whether
this is TRT to do, as the locore clock interrupt code does have to check
for other soft events on return from the interrupt handler anyway.

> I think it would be a great improvement if tsleep() panics
> if called from an interrupt context instead of doing something
> weird (and panic somewhere deeper down if curproc==0).

Hmm, while you can be sure to be in interrupt context if curproc==0,
this doesn't hold the other way around.  I.e., if there happens to be
a process running when your interrupt handler calls tsleep, at first
hand this poor process will be put to sleep.  Depending on the port
you are running on (things like separate interrupt stacks for example
would influence this), there might not be any real problem with this
(without too much thought (i.e. don't cite me on that :-)) this seems
to be the case, if the lowlevel interrupt mechanism uses the user stack
to handler interrupts), or the hell will brake loose when tsleep
tries to return (e.g. with a stack that may be overwritten by some
other interrupt in between).

Yes, it's probably a good idea to make tsleep panic if called from an
interrupt handler.  It does however require coordinated changes to all
ports' locore code.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800