terminology poll: what would you call the part of the operating system that is responsible for managing the pseudoterminal device? (handling ioctls, tracking the foreground process, remembering the terminal window size, turning `Ctrl+C` into a SIGTERM, handling `Ctrl+S` and `Ctrl+W`, etc)
(also open to hearing that you think that it's not just one thing or anything else really)
all of the code for this stuff (terminal ioctls, process groups, window size, signals, Ctrl+W, etc) in Linux seems to be in `drivers/tty` which kinda makes me want to call it this component the “TTY driver" (which helpfully implies the existence of a TTY device, which is an important thing)
(2/?)
IIRC old days each interactive terminal was controlled through a pair of drivers:
The tty driver contained the interfaces that the application program (cat, vi, etc) would interact with, supporting the ioctl calls.
Then inside the kernel the tty driver connected with the driver for the actual device, usually a serial port. Or the tty driver could connect to a pty (pseudo terminal) driver openable by another application e.g. the telnet server process, or (later) a terminal window.
@rjbs I think it's mostly all in drivers/tty in linux, so the code does seem to be mostly in the same place?
like here's some stuff about process group leader tracking: https://github.com/torvalds/linux/blob/9d7a0577c9db35c4cc52db90bc415ea248446472/drivers/tty/tty_jobctrl.c#L98-L108
and I think ctrl+w is handled something like here: https://github.com/torvalds/linux/blob/9d7a0577c9db35c4cc52db90bc415ea248446472/drivers/tty/n_tty.c#L1258-L1263
@b0rk I can't speak for the organization of the Linux kernel's source code; I'm not a Linux kernel developer. In Unix, it was in `sys/tty.c`, which has a comment at the front:
/*
* general TTY subroutines
*/
i.e., it's a library of functions to implement the things required by TTY drivers. As more functions have been added over time, functions have been split out into other source files (there are 7 sys/tty*.c files by 4.3BSD in 1986) but it's always been core device-independent kernel code.
@b0rk I feel it's not just one thing but that's because I know too much about the Unix underpinnings, where it is (at least traditionally) a combination of a kernel driver (allocation, ioctls, etc) and the line discipline (handling Ctrl characters and their actions).
(In practice I think there is some combination of a generic tty driver and then specific drivers for eg ptys, serial terminals, the video console, etc. Line disciplines are generic across all of them.)
@cks hm yeah in Linux it seems like there's a bunch of generic code and then specific subfolders for "vt", "serial", "serdev", "ipwireless", and "hvc" (not sure what the last 3 are)
Is it even in the operating system?
My terminal program (kitty most recently) has a config to say things like "when I type ctrl-c - send 'interrupt'" - so clearly it's not just the OS on the machine I am ssh'd into that handles that.
In my "understanding" (which may be entirely wrong, lol) - it's a game of telephone. I hit ctrl-C - and a sequence of entities get to decide what happens. My local keyboard driver might remap that before handing it to kitty, who may or may not pass that thru ssh to the server I am logged into, terminal driver, pty, shells, etc etc. - with any element in the chain having the capacity to pass that along or change it. So - there's no single entity to pin the blame on.
I think that was the original/default setting - and it was breaking vim. And while I am a wily haxxor, I try to avoid vim configs because it never ends well for me.
@tbortels @gomijacogeo ah I see -- yeah I guess the deal is that kitty can make ctrl+c copy to the clipboard if it wants, but it can't map Ctrl+C to something _other_ than interrupt, like for example it can't make `Ctrl+C` send a different signal. only the operating system can do that
(but it would be extremely weird for someone to reconfigure Ctrl+C at the OS level to do something other than "interrupt" so it's fair of kitty to assume that's what it does)
So - some of the actions you can map to any key (not just ctrl-C) are "send_key", "send_text" (woo macros!) and "send_signal" to "Send the specified SIGNAL to the foreground process in the active window" - they give SIGTERM as the example.
The OS (or the program in the foreground) could choose to ignore most signals, of course. This is why I picked "other" - I think the responsibility for "what happens when I ctrl-C" is a group consensus thing, with the message getting passed along the chain until someone decides to stop passing it along.
I'm surprised this thing can't take out the trash and feed my dog.
Heh - that's terrifying. Good find.
You're probably right - the "i'll just look at context and do the right thing" seemed suspiciously like magic - and it was, at least for my vim config.
Is ok - I kinda prefer "cut" and "interrupt" to be different keys.
Here's the relevant line in ~/.config/kitty.kitty.conf:
map ctrl+c interrupt
I had to set it explicitly because IIRC it was trying to do a "cut" for cut and paste rather than interrupt by default in vim. I assume this makes kitty replace "send ASCII decimal 3" with "send the xterm terminal escape codes for break". Or somesuch equivalent.
To save a google for anyone wanting to dig deeper: https://sw.kovidgoyal.net/kitty/conf/
I rather like kitty. 😃
@b0rk
> the part of the operating system that is responsible for managing the pseudoterminal device
Gotta admit that this is so obscure that, if it is different from “terminal driver”, I don't understand what would make the difference.
@b0rk
> line discipline
I don't know what term I would use for it.
I do know that “line discipline” strongly sounds like a *protocol* (like UTF-8 or SMTP), not a part of an operating system. If someone pointed to a software subsystem and said “that's the line discipline”, that would just confuse; it sounds like saying
“that's the handshake” and sounds like they bungled the sentence.
For a software subsystem *implementing* “line discipline”, I'd demand a better term.
@b0rk
I think they were planning to have multiple line disciplines to choose from. I vaguely recall something about an "old ldisc" vs. "new ldisc". If you use a serial port for PPP it would use the "ppp ldisc".
To be explicit, the line discipline is the code that decides what to do with the incoming characters, such as ^U and ^C. And which ones to send. The tty driver actually sends and receives them from the serial port.
@bignose
Julia Evans
Farce Majeure
Weasel
C. Scott Ananian (he/him)
tbodt
Matt McIrvin
Scali
Chris Warwick
Ricardo Signes 
Norman Wilson
Garrett Wollman
Erik Bosman
Chris Siebenmann
Ariadne Conill 🐰
Tom Bortels
Gomijacogeo
Stephen Greenham
bignose
Rhialto