BTW, as it would happen, all of the 68k ports already contain an
acceptable (albeit non-optimal) splsched().  To wit:

./amiga/include/psl.h:#define splsched()        spl7()
./amiga/include/psl.h:#define splsched()        spl4()
./atari/include/intr.h:#define splsched()       spl7()
./hp300/include/param.h:#define splsched()      spl7()
./mac68k/include/psl.h:#define  splsched()      spl7()  /* disallow scheduling */
./mvme68k/include/param.h:#define splsched()      spl7()
./sun3/include/psl.h:#define splsched()      spl7()
./sun3x/include/psl.h:#define splsched()      spl7()
./x68k/include/param.h:#define splsched()      spl7()  /* disallow scheduling */

So these ports are already `safe'.  Although the comments may mislead
someone; `scheduling' in this context means `running the scheduler',
not task switching.  Task switching (currently) only happens at
precise delay points or when exiting to user mode, so it's outside the
scope of spl.


The pc532 port, however, contains information which is incorrect:

./pc532/fpu/README:         ss = splsched();    /* Note 1 */
./pc532/fpu/README:    run ieee_handle_exception at splsched.

Since the FP handler may register signals (and thus affect the
scheduling-related data structures I mentioned before), it is not
appropriate for it to use splsched().  

It's not clear to me why this code would use spl anyway.  It only
needs to prevent task switching, and it does that implicitly by the
fact that it's running at all.

However, the port doesn't actually implement or use splsched(), so
this is mostly irrelevant.