>Or, to avoid putting too much in kernel space, the tty subsystem could live in a user-space daemon
On Unix, that's what "pseudo ttys" are for (i.e. /dev/pty*)!
For example, that's how Emacs lets you run multiple shell sessions in sub-processes, such that they have full job control (i.e. ^Z and ^C works to interrupt or stop sub-processes in the shell, since they're handled by the TTY). That's also how xterm and the Mac Terminal emulator work, providing the shell sub-process with its own pseudo tty with job control, even though there's not a corresponding /dev/tty* serial port driver. It's like a virtual serial port using a device driver with "TTY Line Discipline" but without an actual TTY.
ChatGPT correctly explains it better than I can or anything I can find with google:
Unix pseudo ttys, or pseudo-terminal devices, such as /dev/pty*, are a key mechanism in Unix and Unix-like operating systems for enabling communication between different processes. Pseudo-terminals are designed to provide the same interface and functionality as physical terminals or terminal emulators. They consist of a pair of devices, the master side (e.g., /dev/ptmx) and the slave side (e.g., /dev/pts/N), which are used to establish a bidirectional communication channel.
Pseudo-terminals are useful for running programs that expect to interact with a terminal, even when there is no actual terminal involved. This is particularly important for terminal-based applications like Emacs, which can run sub-shells within their own window or buffer.
Emacs, an extensible and highly customizable text editor, can leverage pseudo-terminals to run sub-shells, like bash or zsh, within its own environment. [Omitted detailed instruction on how Emacs sets up a pty for a sub-shell.]
By utilizing pseudo-terminals, Emacs can provide an integrated environment where users can work with both text files and interactive shell sessions seamlessly. This enhances productivity and enables users to harness the full power of Emacs' editing and navigation features while working with the shell.
> >Or, to avoid putting too much in kernel space, the tty subsystem could live in a user-space daemon
> On Unix, that's what "pseudo ttys" are for (i.e. /dev/pty*)!
No, that’s not what I was talking about. On just about every Unix, even with ptys, the line discipline code (or STREAMS modules for SysV-derived systems) still runs in kernel mode.
On Linux, you could implement something like what I was talking about with CUSE - have a character device which implemented the termios ioctls in a user-space daemon instead of in the kernel tty driver. That’s very different from how most Unix systems implement ptys
But what I was actually thinking about was a daemon which exposed over IPC an API a lot richer than termios. Something closer to curses.
On Unix, that's what "pseudo ttys" are for (i.e. /dev/pty*)!
For example, that's how Emacs lets you run multiple shell sessions in sub-processes, such that they have full job control (i.e. ^Z and ^C works to interrupt or stop sub-processes in the shell, since they're handled by the TTY). That's also how xterm and the Mac Terminal emulator work, providing the shell sub-process with its own pseudo tty with job control, even though there's not a corresponding /dev/tty* serial port driver. It's like a virtual serial port using a device driver with "TTY Line Discipline" but without an actual TTY.
https://docs.kernel.org/driver-api/tty/tty_ldisc.html
https://en.wikipedia.org/wiki/Line_discipline
ChatGPT correctly explains it better than I can or anything I can find with google:
Unix pseudo ttys, or pseudo-terminal devices, such as /dev/pty*, are a key mechanism in Unix and Unix-like operating systems for enabling communication between different processes. Pseudo-terminals are designed to provide the same interface and functionality as physical terminals or terminal emulators. They consist of a pair of devices, the master side (e.g., /dev/ptmx) and the slave side (e.g., /dev/pts/N), which are used to establish a bidirectional communication channel.
Pseudo-terminals are useful for running programs that expect to interact with a terminal, even when there is no actual terminal involved. This is particularly important for terminal-based applications like Emacs, which can run sub-shells within their own window or buffer.
Emacs, an extensible and highly customizable text editor, can leverage pseudo-terminals to run sub-shells, like bash or zsh, within its own environment. [Omitted detailed instruction on how Emacs sets up a pty for a sub-shell.]
By utilizing pseudo-terminals, Emacs can provide an integrated environment where users can work with both text files and interactive shell sessions seamlessly. This enhances productivity and enables users to harness the full power of Emacs' editing and navigation features while working with the shell.