User: Password:
|
|
Subscribe / Log in / New account

Getting a new tty pot

Getting a new tty pot

Posted Jul 30, 2009 1:10 UTC (Thu) by PaulWay (subscriber, #45600)
Parent article: A tempest in a tty pot

It occurs to me that what the TTY interface needs is a replanning. Something like:

1: Work up a new interface ('nu-serial') that communicates serial data and related out-of-band information in a sensible, linear way. Don't design this to comply with RS-232, RS-422 or anything - design it to work with data and userspace requirements.
2: Convert userspace programs across to this new interface.
3: Write the TTY driver to connect to the nu-serial interface.
4: Optimise the nu-serial interface to work well with threads and across cores.
5: Phase out the old TTY interface.
6: Profit.

The problem seems to me to be that everyone's got a slightly different interpretation of what a TTY should do, and it's being bolted into a whole bunch of things like ppp, KDE and emacs that are needing quite different things from the serial interface. If there's already something like nu-serial, then so much the better.

I'm not a kernel developer, though, so I have no ability to either implement it or guide the project. Some might argue that I shouldn't be saying anything. It does seem to me, however, that this is the approach that's been taken in the past with other things - libata, memory allocators, or schedulers being the first (bad) examples that pop into my head.

Have fun,

Paul


(Log in to post comments)

Getting a new tty pot

Posted Jul 30, 2009 1:20 UTC (Thu) by corbet (editor, #1) [Link]

The real problem here, of course, is step 2. The current TTY interface is a little brutal at times, but it's standard and a lot of programs have been written to it. A new user-space API would be painful to bring in, and we'd still have to support the old one forever.

Past history in this area is not greatly encouraging either. Solaris tried more-or-less what you suggest; the result was called "streams." If you've never had to deal with those, count your blessings.

Getting a new tty pot

Posted Jul 30, 2009 8:08 UTC (Thu) by nix (subscriber, #2304) [Link]

The *problem* is also step 2, of course. The TTY layer isn't complicated
by its need to conform to RS232 or whatever. It's complicated by its
horrendously arcane userspace interface (what is it, *two* chapters in
APUE?), which is the very thing whose behaviour must be preserved.

Getting a new tty pot

Posted Jul 30, 2009 7:39 UTC (Thu) by iq-0 (subscriber, #36655) [Link]

The problem is in number 2, as many applications try to be os independent (or at least unix-flavor
independent).
This is the point that most people don't seem to grasp and perhaps why Linus was so harsh: Emacs
works on a large number of unixes, why is a breakage on Linux the fault of Emacs? Sure it may be
bug, but that would make it a bug that exists outside of Linux and the main purpose of Linux is and
was to be a independent unix-like posix compatible operation system.
This also means that probably Emacs (by virtue of it being a widely used application) was just first
to be impacted by this behavior. And since other applications are probably also directly impacted by
this change of semantics (read: effective ABI change) is not desirable.

The KDE bug is different in that there is a clear indication that it would also not work on other
unixes and probably went unnoticed due to different defaults in distributing KDE which caused that
part to be hardly used (or perhaps some ports has a local patch to fix it which never got upstream).

Getting a new tty pot

Posted Jul 30, 2009 8:07 UTC (Thu) by nix (subscriber, #2304) [Link]

Just because something works doesn't mean it's not buggy. I don't know
about Emacs, but XEmacs's TTY code has had data-losing bugs before, and
worked on heaps of platforms until Linux 2.6 came along, when it started
doing exactly what we see Emacs doing now, losing the end of compilations
(but for a different underlying reason). It can happen.

Getting a new tty pot

Posted Jul 30, 2009 12:50 UTC (Thu) by foom (subscriber, #14868) [Link]

I've seen that same buggy behavior of emacs losing the tail ends of compilations on various versions of OSX. I think it's fixed now, I have no idea if it was fixed in the kernel or in emacs, and I don't know if it's the same underlying cause or not...but it seems suspicious.

So the claim that this new version of Linux is fundamentally breaking the Unix ABI and that emacs worked fine with all other OSes is not all at obvious!

Getting a new tty pot

Posted Aug 2, 2009 11:10 UTC (Sun) by iq-0 (subscriber, #36655) [Link]

True, but it is not obvious that it's the other way round either. My point was merely that in these
cases (where we have a cross platform application) it's safer to assume the kernel is at fault until
proven otherwise. Which in these more obscure interactions between programs and kernels
probably means doing some research on what other systems do.
I'm not saying that always following the lead of other is better, but a standard is defined by it's
implementations and if all implementations make more or less the same (possibly) wrong
assumptions, those wrong assumptions arguably are the standard.
Even this doesn't mean we shouldn't deviate from that standard but doing so (breaking lines with
this implicit standard) probably does effectively constitute as a ABI change.

But it all comes down to wether it is more reasonable to play the "guilty until proven innocent"
versus the "innocent until proven guilty" card in these cases. Both (logically) in the end lead to the
same conclusion (if the problem is deterministic of course).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds