Re: term & user space console

[Thomas Bushnell, BSG]

tb@becket.net (Thomas Bushnell, BSG) writes:

> > The pty interface does also not handle START and STOP.  It stores
> > the state in flags, but it does not make use of it in any way.
> 
> That's a bug.

There should be no bug here.  Output happens under the control of
pty_io_read, and it does in fact check USER_OUTPUT_SUSP; if the flag
is set, then it doesn't allow the read to continue.

> It's really the responsibility of the bottom handler.  For START and
> STOP, it's important to use the underlying filesystem *if* it
> implements the calls, otherwise, just do it in the bottom handler.
> (The reason is that buffering may be going on further down.)  I would
> suggest trying the appropriate ioctl calls; if they fail, then do it
> in the bottom handler.  Probably the same strategy should be used for
> Mach devices.

Ok, what I wrote here was confusing and wrong.

For START and STOP, the deal is that the upper half sets
USER_SUSPEND_OUTPUT, and calls suspend_physical_output.  That function
should, if needed, set a local bit (called "output_stopped" in the
existing drivers) and also tell the underlying thing to try and stop
output.  The start_output function (and wherever else) are responsible
for making sure that if USER_SUSPEND_OUTPUT is set, no output happens.