Preferences

> Beware, though: What you are about to see is not particularly elegant. In fact, the TTY subsystem — while quite functional from a user's point of view — is a twisty little mess of special cases.

I wonder if it is about time someone tried to build something more elegant. If someone was inventing something like the TTY subsystem from scratch today, with no requirements for backward compatibility, what would they do differently?


tyingq
IBM's approach (3270) was pretty different. More structured, with control blocks, first class support for things like user editable fields, etc.

http://www.tommysprinkle.com/mvs/P3270/start.htm

rogual
I'd want to investigate not relying on in-band signalling for terminal control. So, perhaps have two input streams: stdin and stdctrl?

Also, it'd be tempting to try and add more structure, but I honestly think bare streams of bytes are the right abstraction at this level.

Careful: when you have OOB signalling, how do you keep the control codes in sync with the data, bearing in mind that both streams may be buffered differently?
GrinningFool
That's a good point. I think ultimately it would still need to be pipelined as if it were in-band. Perhaps synchronization codes with a timestamp/uuid that corresponds to point-in-time against the data.
skissane OP
> Also, it'd be tempting to try and add more structure, but I honestly think bare streams of bytes are the right abstraction at this level.

Most contemporary terminal streams use escape sequences which are based on ECMA-48 with a bunch of de facto standard extensions, so that isn't really a bare stream of bytes. It is an overly complex encoding and ideally would be replaced with something more elegant. (Of course, strictly speaking kernel space largely doesn't deal with ECMA-48 and that is left to user-space libraries such as terminfo/readline/ncurses/etc, but it is part of the overall architecture.) As well as escape sequences, most contemporary terminal streams use UTF-8 as well, so that's another way in which they are no longer bare byte streams.

Do we need line disciplines in the kernel? I think the answer is that historically line disciplines were implemented in Unix before shared libraries were. If shared libraries had been implemented earlier, line disciplines could have been implemented in user space as shared libraries instead of in the kernel.

They'd make it a web service in a locked-in walled garden.

This item has no comments currently.