re: CVS commit: src/sys/dev/ic

[matthew green <mrg%eterna.com.au@localhost>]

> > also, what's IST_MPSAFE?  sounds like some platform specific
> > thing.
> 
> Sure. Each platform should have it's own. Unless someone wants to make an
> MI intr_establish.

then it's not useful for MI driver.

you quote spl(9):

>    At the time of writing, the global kernel_lock is automatically
>    acquired for interrupts at this level, in order to support
>    device drivers that do not provide their own multiprocessor syn-
>    chronization.  A future release of the system may allow the
>    automatic acquisition of kernel_lock to be disabled for individ-
>    ual interrupt handlers.

and then:

> >  in MI drivers IPL_VM vs IPL_SCHED is the mpsafe tag.
> 
> Not according to spl(9).

my point is that when you use IPL_VM you may end up taking the
kernel lock even if you don't need it.  it implies "not mpsafe".

back when ad reduced things to the current level, the plan
would have been to obsolete IPL_VM entirely and simply have one
level between IPL_NONE and IPL_HIGH, but that was too hard to
do all at once, and IPL_VM for old code was kept, with the
advice to avoid IPL_VM for the future.

note that pretty much all other modern platforms have obsoleted
any ability to block some interrupts -- you either block or
allow -- and they have been shown to remain performant, so while
we can talk about the ability to block some but not higher level
interupts from what i can tell about modern compupting, it
doesn't really matter any more.

(in my world view, the restriction differences between IPL_VM
and IPL_SCHED should be removed, and kmem should be allowed
in interrupt handlers -- we've had kmem_intr_alloc() as the
real back end for over 10 years at this point, time to accept
it as the reality.)

> > if you're wanting to restore some level for drivers to use
> > below IPL_SCHED, that may be a reasonable thing to consider
> > (though it's been abandoned by most platforms AFAICT), but
> > that will require a fairly large rearrangement of spl(9)
> > and the interfaces -- either adding a new level entirely
> > (IPL_VMSAFE? :-) or adding an mpsafe tag everywhere, so i'm
> > really not sure it's a good idea.
> 
> Why is the latter not possible?

that latter is possible, but it's fairly huge change --
how many MI calls to *intr_establish() exist that will
need to be udpate?


.mrg.