@kai: your qs reg which context bottom-halves execute in?
Technically, softirq's do run in an interrupt context - the "softirq" context; it's just that it's not "hard-irq" context (which is the context when a hardware interrupt occurs).
So, in a softirq handler, in terms of the 'lookup' macros Linux provides:
in_interrupt: yes | in_irq: no | in_softirq: yes | in_serving_softirq: yes
But be aware (beware!!! :):
"all of the restrictions that apply to interrupt handlers also apply to bottom halves. Thus, bottom halves cannot sleep, cannot access user space, and cannot invoke the scheduler." -- LDD3.
Jermaine answers the rest of your question.
[Update]
In addition, I'd like to point out that one can define simple and elegant macros that help print debug info as and when required. Over the years, I've put these macros and convenience routines into a header file; you can check it out and download it here: "A Header of Convenience".
There are macros / functions to:
- make debug prints along with funcname / line# info (via the usual
printk() or trace_printk()) and only if DEBUG mode is On
- dump the kernel-mode stack
- print the current context (process or interrupt along with flags in the form that ftrace uses)
- a simple assert() macro (!)
- a cpu-intensive DELAY_LOOP (useful for test rigs that must spin on the processor)
- an equivalent to usermode sleep functionality
- a function to calculate the time delta given two timestamps (timeval structs)
- convert decimal to binary, and
- a few more.
Whew :-)