[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: term & user space console

From: Thomas Bushnell, BSG
Subject: Re: term & user space console
Date: 18 Dec 2001 13:44:08 -0800
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]