I wrote:
> So interrupts won't be lost, but other processes won't be scheduled.
> I doubt any noticeable effect during ordinary sequenced music (short
> bursts with macroscopic delays between). For large bulk transfers
> (patch dumps and such), the safety valve is the size of the output
> buffer and the ordinary scheduling of the writing process.

I suppose it's not quite that easy, because under that scheme, in
the polled case, start_output (called by the top half during a
write call) will not return until the buffer is empty, so the top
half will never see the buffer full, and never have a reason to
sleep. If there is more to write (the process made a humongous
write(2) request), the loop in midiwrite will blithely continue
filling the buffer and calling start_output to empty it all, and
still no other process can be scheduled until the whole request
completes. :/

But it seems to me the better solution in that case is not to fuss
with a callout and some arbitrary delay, but for the top half to
do a yield() or preempt() in that loop before calling start_output
again, if attached to polled hw. That's assuming those routines in
kern_synch.c will really do what I think. That way there's a chance
to schedule some other process that's become runnable before the
entire write(2) request completes, but we stay runnable and if there's
nothing else to do or we're still highest priority, we continue the
transfer with no arbitrary delay.

Will those routines do what I think, assuming I've splx'd and
released any locks I've acquired at that point? Is yield() or
preempt() preferable for the purpose? The difference seems a
bit subtle.

-Chap