Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: tty driver advice
Message-ID: <14304@sun.uucp>
Date: Sat, 28-Feb-87 23:52:01 EST
Article-I.D.: sun.14304
Posted: Sat Feb 28 23:52:01 1987
Date-Received: Mon, 2-Mar-87 05:13:54 EST
References: <75@pixdoc.UUCP> <5623@mimsy.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 29

>>This could be done just fine on the user side of the input queue.
>
>Only if you are willing to give up one of two things:  Proper
>backspacing, or immediate echo.

A streams-based driver could do the canonicalization in a service
procedure; they are not run at interrupt priority level.  However,
you may have to run some of the code at interrupt priority level
anyway, to prevent an interrupt routine from asynchronously smashing
data structures used by the canonicalization code (this being a price
you pay for extensively using "spl" routines to do mutual exclusion,
as UNIX does).

However, Chris's point that doing it at read time requires you to
give up one of those two things still stands; I am unwilling to give
up either one (and I suspect a lot of other people are also unwilling
to give them up).

If somebody shows me some evidence that so much work is done at
interrupt priority in such a scheme that it causes significant
problems, I might consider it (although I'd be more likely to
consider implementations that permitted more sophisticated methods of
mutual exclusion).

However, I tend to suspect that it does *not* cause a problem,
because at one point Jack Slingwine at CCI profiled how much time was
spent at interrupt priority in various routines in 4.2BSD (the
results should be applicable to most other UNIX implementations) and
the *disk* driver won by far.  (How fast *can* you type, after all?)