Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!wivax!cadmus!harvard!seismo!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.unix Subject: Re: 8 bit I/O vs 4BSD Message-ID: <1389@umcp-cs.UUCP> Date: Tue, 27-Nov-84 13:33:15 EST Article-I.D.: umcp-cs.1389 Posted: Tue Nov 27 13:33:15 1984 Date-Received: Fri, 30-Nov-84 08:41:47 EST References: <477@sdcsvax.UUCP> <1165@umcp-cs.UUCP> <254@bragvax.UUCP> <522@watcgl.UUCP> Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 34 I think everyone realizes that if you are going to preempt characters for flow control, they aren't going to be available for data. You *can* have an 8 bit data path in *both* directions *and* have flow control; you just have to give up at least one character (it can still be sent by using some kind of protocol, of course). However, the Berkeley tty drivers just don't allow it. Here's what goes wrong, at least, what I can think of easily (I haven't tried to implement 8 bits myself): (1) delays can't be done by meta characters [this is a problem with LITOUT mode too!]; (2) what if you want the input character '\377' as a special character?; (3) how do you tell how many bits should be used to check for special characters; i.e., is meta-^S a stop character or not?; (4) You have to change every single da[rm]ned device driver to do things differently because of (1-3). Speaking of flow control, has anyone ever thought about how much problems using in-band data for this has caused? If terminals had hardware flow control, we might not have kludges like the pty driver sending special packets whenever t_startc and t_stopc change from/to ^Q/^S, and rlogind flushing perfectly good data just to get that OOB data, and . . . [froth froth]. Have you ever noticed that the pty driver *doesn't* send any messages about any other state changes (like raw mode?) [rant rant]. You'd think that if Berkeley saw fit to provide info about changes in local flow control on a network port to the program doing the connecting, they'd also see fit to provide nice ways to get the entire state across, not just one tiny bit [rave rave]. I'd better stop, I'm getting out of hand here. Maybe I should add net.flame.... :-) -- (This line accidently left nonblank.) In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690 UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland