4 ms·

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 t

• skissane 10y ago
  > 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.
• pjc50 10y ago
  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 10y ago
    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.