In message <20050607004001.GB1761@netbsd.org>,
Bill Studenmund writes:

>I guess my confusion is that don't we have interrupt handlers grab the big
>lock now? So don't we have an implicit mono-leveling now?

Yes. however, I recall considerable distaste for merely exchanging the
big-lock choke point for a choke-point whereby MD code flattens all
device interrupts to a single IPL level. (Though purely selfishly,
that _would_ let me run multiple instances of SMP-safe drivers
concurrently with a single CPU at splsoftnet().)

>Or is that it's important to have the big lock and one or more separate
>interrupt locks?

I think it's even more simple than that.  After the last couple of
emails, I beleive Yamamoto-san and I are in complete agreement about
where we want to end up. Yamamoto is correct, the IPL-locking is
clearly an interim solution.  I think Yamamoto-san and I really
disagree only over how long that "interim" is likely to be.


I fear the "rework entire IPL" will take long enough that the
IPL-locking SPL*()s will be around for quite some time -- more than
long enough to be well worth its keep. (OTOH, I'd be very glad
to be wrong).


I don't mean to point fingers at any other group, but if you look at
other open-source projects, and how long they've have taken to get
from a stable "big lock" kernel to a stable biglock-free kernel, with
"all at once" approaches, then an incremental, piecmeal-testable,
piecmeal-deployable approach starts to look like a pretty reasonable
idea.

Besides, I'm impatient, I want to start working on SMP-safe network
drivers, oh, last month.