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

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

Nick Hudson writes:
> On 30/05/2019 21:46, matthew green wrote:
> >> Committed By:	tnn
> >> Date:		Thu May 30 07:37:17 UTC 2019
> >>
> >> Modified Files:
> >> 	src/sys/dev/ic: ssdfb.c
> >>
> >> Log Message:
> >> - include uvm.h before uvm_device.h
> >> - don't need IPL_SCHED here
> >
> > the IPL_SCHED change seems backwards to me.
> >
> > IPL_VM is the "this driver is not updated to MPSAFE yet" level,
> > but IPL_SCHED is the MPSAFE level.
> >
> > ie, we should be striving to remove any uses of IPL_VM, not
> > moving (back) to them.
> 
> In my view we should be using IPL_VM + IST_MPSAFE (and not IPL_SCHED) if
> the driver is MPSAFE.

why?

IPL_VM is basically synonymous with !MPSAFE in the current
kernel -- lots of subsystems will take kernel lock if you 
use IPL_VM.

also, what's IST_MPSAFE?  sounds like some platform specific
thing.  in MI drivers IPL_VM vs IPL_SCHED is the mpsafe tag.

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.

for now, IPL_VM should be avoided for MPSAFE code.


.mrg.