On Thu, Feb 22, 2007 at 08:37:41PM -0800, Bucky Katz wrote:
quoted text
> Bill Studenmund <wrstuden@netbsd.org> writes:
>=20
> > As I understand it, the difficulty comes in when the mutex is held
> > by a thread that is not running. In that case, the interrupt handler
> > blocks. In that case, the interrupt handler has to be blocked, and
> > the interrupt has to be disabled/ignored until serviced. For systems
> > with a PIC, we disable the interrupt and cope.
>=20
> I don't understand Andrew's design well enough to comment directly on
> it, but "interrupt handler blocks" in interrupt context is something
> that leads to much difficulty in OS design.=20

The design we're talking about is very strongly inspired by the Solaris=20
model.

Yes, I agree that an interupt handler blocking is a bad thing. We should=20
not do it much at all.

quoted text
> On the other hand, the top/bottom model in which bottom halfs run in
> interrupt context with interrupts disabled but aren't allowed to block
> and top halfs run in kernel thread context with interrupts enabled
> (suitably adjusted for interrupt priority levels on appropriate
> architectures) has a long history, scales nicely, and is well
> understood. It can also use lock-free communication between the top
> and bottom halfs when properly implemented.

Given that the desire is to run the interrupt "thread" by borrowing the=20
context of the interrupted thread, we will have mostly the same thing as=20
now. It took me a while to figure this out.

quoted text
> It may be more work to get there, but it's an incremental change from
> the current NetBSD model, and drivers could be converted as needed,
> rather than trying to get everything right in one fell swoop.

The paragraph above actually is one selling point of what Andy's suggested
so far. :-) For architectures (platforms) with a PIC, my understanding is
the x86 change should be a model that can be cookie-cuttered around. There
are issues with modal architectures (ones with a separate interrupt
stack), so we aren't done yet. But we're getting there.

A big part of the win is that we can then make interrupt handlers not need=
=20
biglock. So we can then start fine-graining the kernel.

Oh, I like the idea of keeping the top/bottom split. I don't want to be=20
doing tons of work in an interrupt thread!

Take care,

Bill