I have a problem that I'd like a better solution to.

The USB stack uses callbacks to inform a caller that a transfer is
complete.  These callbacks are currently executed from the USB
host controller interrupt routine.  This is problematic since the
callback will have to raise the spl to many different levels (spltty()
for the modem driver, splbio() for the mass storage driver, splimp()
for the Ethernet drivers, etc.)  Note that this must be a RAISE of the
level, otherwise the USB interrupt routine could interrupt things
it shouldn't
.
As I see it there are three different solutions:
 * Use the lowest possible physical spl level for USB.  This is what I
   do today; hoping that splbio() is lower than the others...
   This is really a hack.
 * Use a soft interrupt level, splsoftusb().  This is a little
   cumbersome since soft levels require low level hacking in all
   ports that need them.
 * Use a kernel thread.  The USB interrupt routine would the just queue
   the callbacks and wake up the kernel thread to do the job.
   This looks like an attractive solution, but...

I want the kernel thread for delivering USB callbacks to run as soon
as it can, and with high priority.  Is it guaranteed that when the
USB (physical) interrupt routine returns there will be a rescheduling
and the USB callback thread will be to run at once (bar other interrupts)?


--

        -- Lennart