Chapman Flack wrote:
> 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.

Not satisfactory either, as there's nothing for "nonblocking write"
to mean in such a design. So the writing to the polled UART has to
be done from a callout. (Which won't make much effective difference on a
uniprocessor; the writing process still won't get many cpu cycles after
its "nonblocking" write until the callout has emptied the buffer, but
on MP it might be more useful.)

Still, it seems desirable to move everything out of the buffer without
arbitrary delays (certainly nothing as long as 10ms), and with as many
interrupts enabled as possible. Are there any foreseeable problems with
using spl0() in the callout, outside of its critical sections, while
spinning on the busy device? That way other unrelated callouts can run.

When a callout is run, does the kernel lock get taken? In that case,
a long-running callout will be an obstacle even to other processors. :/
Maybe there's no point expending much effort to worry about performance
when talking to midi hardware that can't interrupt.

And the callout-free strategy where the top half yields is certainly
simpler. And there is something for "nonblocking" to mean after all:
I could return a short write count after writing one buffer, rather
than yielding. Doesn't mean you weren't held up waiting for the UART,
but does mean you weren't blocked in the sense of incurring a context
switch. Maybe that's close enough for this game.

-Chap