linusakesson.net

Forum comments in chronological order

Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.

Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.

Jul 2025

The TTY demystified

Anonymous
Thu 10-Jul-2025 13:26

marky wrote:

Sadly, this nice property seems to break over SSH, as I recently lamented about at stack overflow, here:

https://stackoverflow.com/questions/78843587/how-to-run-ssh-in-the-background-without-writing-my-own-os-kernel-and-ssh-server

Sadly, the internet is so broken there's no good place for you to post things that doesn't get deleted. Even eternal-september is removing knowledge at an astonishing rate.
Anonymous
Thu 10-Jul-2025 13:55

marky wrote:

Sadly, this nice property seems to break over SSH, as I recently lamented about at stack overflow, here:

[ https://web.archive.org/web/20250126093803/https://stackoverflow.com/questions/78843587/how-to-run-ssh-in-the-background-without-writing-my-own-os-kernel-and-ssh-server ]

To fix this issue, I think we'd need new kernel APIs and a change to the SSH protocol

What's the problem? That ssh doesn't pass on job control responsibilities to the other end? You need to run something of this structure in lieu of something more transparent?

myend -- ssh args... 'yourend -- cmd args...'

tty muxing and relaying looks impossible to do exactly right without a new line discipline or two so terminal state changes can be relayed and data that varies with state can be conditionally delayed until states ar esynchronised.

It kinda looks like new line discipline(s) are the place to do it.
It looks like, despite comments around the internet of a mythical RAW line discipline, Linux offers only N_TTY and N_NONE, neither of which looks suitable as a basis for tty relaying.

I can't bear to imagine the hurdles tmux must go through to do the right thing. I can only imagine they give up on terminals that show the termios flags to the user.

The real tty needs to be given the flags of the pty and vice-versa, whenever those change at either end, but features of the line discipline need to be "secretly" off via the pty master rather than being switched off for relaying in the slave pty or real tty termios, or by trying to convert streams in between. terminal types need to be generalised to intersections of types and applications need to advise what types from the terminfo database they support for inclusion in the intersection so applications can adjust themselves to suit the relay pipeline even when its just one real and one pseudo.
Anonymous
Fri 11-Jul-2025 00:48
It looks like, despite comments around the internet of a mythical RAW line discipline, Linux offers only N_TTY and N_NONE, neither of which looks suitable as a basis for tty relaying.

I had relied on the list in /proc/tty/ldiscs which I found referenced as a list of available line disciplines. I now think that's populated from loaded kernel modules (and built in ones if nonmodular kernels still exist) but no N_RAW that I can see in /usr/include/linux/tty.h


0-1999:linux# cat /proc/tty/ldiscs
n_tty 0
n_null 27
0-2000:linux# modprobe slip
0-2001:linux# cat /proc/tty/ldiscs
n_tty 0
slip 1
n_null 27
0-2002:linux# rmmod slip
0-2003:linux# cat /proc/tty/ldiscs
n_tty 0
n_null 27
Anonymous
Fri 11-Jul-2025 01:30
There are various ioctls for ttys in several layers, at least:

tty layer
tty devices low-level driver
line discipline

man tty_ioctl has some information about some of them.

There seem to be some synchronisation, buffered char counts and fake input methods that might make an approximation of transparent relaying practical, including even synchronisation of streams with termios changes, perhaps tmux, screen and sudo use them.

For your ssh solution see how well sudo does it using its 'monitor'. see man sudo for an outline.