An alternative TTY layer

Posted Apr 27, 2017 20:06 UTC (Thu) by post-factum (subscriber, #53836)
Parent article: An alternative TTY layer

Indeed, duplicating the code must be a no-no.

But since current TTY subsystem is a huge mess, it worth throwing it out, replacing with something equivalent but properly architected.

If such an effort is started already, why stopping with minimal implementation? If designed properly, optional layers might be disabled if necessary.

An alternative TTY layer

Posted Apr 27, 2017 22:52 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

TTY subsystem is hairy but not excessively badly designed. It just has the usual abstraction overhead penalty.

An alternative TTY layer

Posted Apr 28, 2017 6:49 UTC (Fri) by josh (subscriber, #17465) [Link] (3 responses)

It does, however, have the problem of an extensive and under-specified userspace semantics, with no comprehensive test suite.

The last time someone tried to significantly overhaul the TTY layer, they ran into obscure issues with bits of the interface that only emacs used, and almost nothing else.

An alternative TTY layer

Posted Apr 28, 2017 6:51 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

But you don't need all the legacy crap for mini-interfaces. Small devices are not likely to run emacs - you're essentially are creating a NEW userspace ABI.

An alternative TTY layer

Posted Apr 28, 2017 22:06 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, indeed. That's why a tiny reimplementation for those small systems only is preferable to uglifying the existing one in an attempt to make all the abstraction layers optional. Throwing out the TTY layer wholesale and replacing it with something "properly architected" (without any evidence that what we have now is poorly architected for its intended use case, which does not include 1MiB RAM IoT boxes), as the original commenter suggested, is quite different.

(A better API without all the horror shows of the existing one around job control, signal handling, ioctls etc would be nice too, but it sounds like minitty just throws most of that out since none of it is needed for its use case -- and for any other use case, the better API would have to coexist with the horrible existing one that everything uses in any case, and because that API is so ancient and widely used there really could never be a sunset period for it -- like it or not, we're stuck with SIOC* forever.)

An alternative TTY layer

Posted May 11, 2017 1:45 UTC (Thu) by geek (guest, #45074) [Link]

OK, who's the emacs maintainer then?

An alternative TTY layer

Posted Apr 29, 2017 1:58 UTC (Sat) by flussence (guest, #85566) [Link]

I wonder if cleaning up the TTY layer would open a path to make the framebuffer console layer less awful. Its emulation of a 1980s dumb terminal—including the redraw speed of one—is a little too accurate for my tastes. This is only getting worse as screen resolutions increase.