Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: comp.bugs.sys5
Subject: Re: Bug in TCSETA ioctl?
Message-ID: <1720@desint.UUCP>
Date: 14 Apr 88 04:21:55 GMT
References: <107@sibyl.eleceng.ua.OZ>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 31

In article <107@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes:

> The hardware tt driver calls ttiocom and if it returns non zero goes and
> stuffs things in the DUART registers to set up baud rates no of stop bits
> etc. Not too surprisingly this tends to corrupt anything the DUART is in
> the process of outputing.

Your hardware driver is broken.  The driver should *never* modify the DUART
settings while characters are still in its output buffers.  With most DUARTs,
there is a way to tell whether the output buffers (usually two of them) are
empty yet.  Your code may have to loop, calling swtch() (and, I think,
setrun()) until those two characters are sent.

> I contend that this code should only return 1 if the HARDWARE setup has
> changed. Many (most?) TCSETAs will NOT change the hardware setup.
> 
> Something like replacing the "return (1);" with
> 
>            if ( old_c_cflag == c_cflag ) break;

In general, it is not possible to predict what tty settings will change the
hardware setup.  On complex hardware, changing iflag or oflag could require
changing the hardware.  Conversely, on many DUARTs, not every bit in cflag
requires a hardware change.

I'd recommend changing the driver to keep track of the current hardware
settings on each port, and to compare these with the new ones whenever
the ioctl routine is called.  If no change is needed, don't change the
hardware unnecessarily.  If something has changed, be sure to wait until
the output buffers have drained before clobbering them.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff