fbp@pixdoc.UUCP (02/26/87)
Does anyone have any suggestions as to where I might find a good example of a tty driver. On all of the systems I have seen to date they seem to be an evolved hack. My biggest pet peave is the processing of ^H at interrupt time. This could be done just fine on the user side of the input queue. Of course the myriads of buffering and "clever" activity at the low levels seem imprudent if not dangerous. Also, If anyone has comments of the various schemes of dynamic tty queues and such, please let them fly. This seems to be less of a science and more of am art (read vodo) from what I can see. Referances to texts like Xinu and Minex are very welcome. Rick ...!harvard!wjh12!pixel!pixdoc!fbp
chris@mimsy.UUCP (02/28/87)
In article <75@pixdoc.UUCP> fbp@pixdoc.UUCP (fbp) writes: >My biggest pet peave is the processing of ^H at interrupt time. (`Peeve'. Sorry; I have seen too many spelling errors recently.) >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. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
guy@gorodish.UUCP (03/01/87)
>>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?)