Interrupt flow in the NetBSD kernel

[Kamil Rytarowski <n54%gmx.com@localhost>]

I have got few questions regarding the interrupt flow in the kernel.
Please tell whether my understanding is correct.

There are software and hardware interrupts.
Part of the hardware interrupts are maskable with the spl(9) levels.
Some are unmaskable and must be handled unconditionally, like the
exception data abort from ARM.
Hardware interrupts are handled by the hardware interrupt handler.
System calls (syscalls) and softint(9) are software interrupts handled
by the same software interrupt handler.
Syscalls come from the userland with the user address space context,
softint(9) come from the kernel with kernel address space context.

The spl(9) calls mask maskable interrupts, both software and hardware
ones - with the exception to the unmaskable ones -- like data abort on ARM.

There are three contexts in the kernel:
- hardware interrupt (within hardware interrupt handler),
- software interrupt (within software interrupt handler) for syscalls
and softint(9),
- thread context for LWP (lightweight processes).

Bottom half (BSD naming) is responsible for the hardware interrupts, top
half (BSD naming) is responsible for the software and thread contexts.

Process is heavy with user address space oneness running in the
user-space, thread is lightweight with shared kernel address space for
all threads. Kernel can access the whole physical memory, but doesn't
know the user address mapping. There is one process running in the
kernel address space -- proc0 = swapper.

How physically works the spl(9) interrupt masking for software
interrupts? On ARM svc (or monitors) aren't maskable, like IRQ
(exception), a type of (ARM naming) exception and (kernel naming)
hardware interrupt.

I'm trying to get the big picture first, before getting to details.

When I look into details, I don't get the things, like the line 268
here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/arm32/exception.S?annotate=1.17.2.2
Is it a leftover from line 252 and should be erased?

Back to the big picture. How technically works IPL_SOFT, does it mask
syscalls and softint(9) the same way? If it's not maskable (to my
understanding) are we scheduling it in some sort of queue or stack
waiting for the spl(9) level change?