3

To be specific, let's speak in pseudo-terminal terms. Suppose we have file descriptors master and slave for a pseudo-terminal pair (suppose it is a controlling tty). Disabling IXON on master (or slave, which works the same) means that when we do write(master, &control_s_code, 1), read(slave, &byte, 1) will get this code. The same concerns control_q_code. The question is: what does disabling IXOFF do?

Igor Liferenko
  • 713

1 Answers1

7

IXOFF is not implemented on pseudo-ttys, and setting IXOFF on a pseudo-tty has no effect whatsoever.

IXOFF should cause the tty driver to send a VSTOP character to the other side when its input queue is full (which should prevent it from sending in more data), and a VSTART character when it has processed it and there's place for more data.

This is different from IXON, which will cause the tty driver to respect the VSTART/VSTOP characters sent from the other side, and upon receiving a VSTOP (^S) character, stop any transmission until a VSTART (^Q) character is received.

In the case of a pseudo-tty, the "other side" is the master pty, eg. your terminal emulator; when you press ^S, it's the IXON, not the IXOFF setting which will cause the slave tty to stop echoing back the entered characters and displaying the data written to it (which will be queued until the output queue is full, when any write(2) to the slave tty will either block or return EAGAIN).

Implementing flow control on pseudo-ttys is not needed, because the kernel always knows (by checking a struct field or similar) whether the input queue of the slave has filled up, and can just block the process writing to the master pty.

The software flow control is only useful when using a real serial connection without out-of-band signals like RTS/CTS: unlike any Unix, TCP or other "pipe" abstraction, a wire is not buffering and will not fill up and block until the receiver has read all the state changes off it.

  • 1
    ok, thanks! I never really got the logic in the ixon/ixoff naming, I always wondered why they're not called "sendxoff" and "recvxoff" or something like that instead. (Anyway, now I can go back to being confused about other things!) – ilkkachu Oct 04 '19 at 09:16
  • What does IXOFF do for an ordinary (i.e., not pseudo) tty? – Igor Liferenko Oct 07 '19 at 03:21
  • Also, your note about absence of need for flow control on pseudo terminals is not known to gnome-terminal (and xterm) developers: pressing ^S in bash can be used to verify this. – Igor Liferenko Oct 07 '19 at 03:23
  • @IgorLiferenko Whether the pty reacts to ^S/^Q is controlled by the IXON, not the IXOFF settings; I've expanded on that in the answer. The terminal emulator doesn't have to care about that at all -- it simply writes the ^S and ^Q characters into the master fd -- it's up to the tty driver to handle or not handle them. –  Oct 07 '19 at 04:52
  • So, IXOFF is the same as IXON, but for the opposite side of the tty. Right? – Igor Liferenko Oct 07 '19 at 05:09
  • You say: "Whether the pty reacts to ^S/^Q is controlled by the IXON, not the IXOFF settings". Why pty is supposed to react to ^S/^Q sent from master side but cannot react to ^S/^Q sent from slave side? I think it should be both or none. – Igor Liferenko Oct 07 '19 at 05:11
  • No. With a real serial line, setting either IXON or IXOFF does not affect in any way what the remote side will do. What may be confusing is that any line discipline ioctls (eg. TIOCSETS* which implement tcsetattr) on the master pty are always acting on the slave pty. The master pty is not a real pty, and does not do any line discipline like flow control or anything, it simply reads and writes raw data to the slave. See this for some details about how it works in Linux. –  Oct 07 '19 at 05:21
  • You say: "setting either IXON or IXOFF does not affect in any way what the remote side will do". But this contradicts to what you said in the answer: "IXOFF should cause the tty driver to send a VSTOP character to the other side". – Igor Liferenko Oct 07 '19 at 05:25
  • Is there any example scenario when disabling IXON on master side of pty may be harmful? – Igor Liferenko Oct 07 '19 at 05:27
  • How could changing any property of the local tty driver affect the system/device at the other end of the wire, whether making it use or not use flow control? –  Oct 07 '19 at 05:28
  • You cannot change any line discipline property on the master pty -- any tcsetattr on the master will only affect the slave. The master fd is simply set to raw mode / pass-through and is not user-serviceable. –  Oct 07 '19 at 05:30
  • If device on the "other side" uses flow control, setting IXOFF on local tty driver will stop the device from sending any more data – Igor Liferenko Oct 07 '19 at 05:30
  • No, it will only cause the local device to send the VSTART/VSTOP characters -- the other side may ignore them or treat them as ordinary characters ;-) –  Oct 07 '19 at 05:31
  • Yes, but if that device does not ignore them, setting local tty attributes will change state of the device. So, saying that changing local tty attributes will change state of device on the other side of the wire, is not wrong. – Igor Liferenko Oct 07 '19 at 05:34
  • Is there any example scenario, when disabling IXON using master fd of pty, may be harmful? I mean, why it was decided to leave possibility of software flow control for pty anyway (for IXON)? – Igor Liferenko Oct 07 '19 at 05:35
  • For example, I patched vte2.91 to disable IXON using master fd right after pty is created (to get rid of annoying effects of pressing ^S in bash and other programs). Is this bad in any way? – Igor Liferenko Oct 07 '19 at 05:39
  • It depends on the app. If it's something like expect, the answer is certainly NO. If it's a terminal emulator, a user may expect to stop scrolling with ^S, and will hate you if she has to look in the manual how to enable it back ;-) –  Oct 07 '19 at 05:40
  • There was no need to patch vte; simply stty -ixon in ~/.bashrc would've worked, too. –  Oct 07 '19 at 05:41
  • In such scenario each program which does not use ^S (e.g., less, bash) must be patched/configured to disable IXON, which is worse than patching just one terminal emulator. And finally I see the use case for ^S/^Q in bash - scrolling! Never occurred to me before. But I deal with this problem in another way - I use unlimited scroll buffer. – Igor Liferenko Oct 07 '19 at 05:43
  • No, simply stty -ixon works -- less, vi or the readline library (as used by bash) will not reenable it back. –  Oct 07 '19 at 05:51