Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!chris
From: chris@umcp-cs.UUCP
Newsgroups: net.bugs.4bsd
Subject: Re: Stupid MORE breaks on a rubout key when it should not
Message-ID: <3311@umcp-cs.UUCP>
Date: Mon, 24-Oct-83 02:51:15 EDT
Article-I.D.: umcp-cs.3311
Posted: Mon Oct 24 02:51:15 1983
Date-Received: Tue, 25-Oct-83 22:58:38 EDT
References: <1667@gatech.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 23

Actually, the entire issue of breaks, framing errors, and interrupt
characters is thorougly mishandled by the Berkeley newtty driver.
The device drivers carefully convert framing errors to the appropriate
character from tp->t_chr (I don't know what they've called it in
4.2).  It should just pass the break as a special magic code, on
up into the higher level protocols.  There should be flags for
ignoring BREAK/FEs, and for generating interrupts regardless of
the interrupt character (or lack thereof, even in RAW mode) when
a BREAK/FE is detected.  (They look the same to most hardware.)

Berkeley should throw the whole thing out and write a new one that's
basically compatible with the System 5 setup, with the addition (of
course) of those ever-so-fun job control characters.

In the meantime, you have two options:  suffer with the noise, or
turn off your interrupt completely (``stty intr u'') -- this will
make all the device drivers ignore BREAK/FEs.

Chris
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris.umcp-cs@CSNet-Relay