[EMAIL PROTECTED] (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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
