> 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.
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.