Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!xlink.net!math.fu-berlin.de!unlisys!max.IN-Berlin.DE!not-for-mail From: berry@max.IN-Berlin.DE (Stefan Behrens) Newsgroups: comp.os.386bsd.questions Subject: Re: Slcompress -- enforce HW flow-control, patch Date: 8 Jul 1993 18:10:40 +0200 Organization: Private Site in Berlin/Germany Lines: 26 Message-ID: <21hgue$5fg@max.in-berlin.de> References: <hastyC9IFM3.F9u@netcom.com> <BLYMN.93Jul6170320@mallee.awadi.com.au> <21f6er$2v7@max.in-berlin.de> <21ffi4$i46@sylvester.cc.utexas.edu> NNTP-Posting-Host: max.in-berlin.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In article <21ffi4$i46@sylvester.cc.utexas.edu> vax@sylvester.cc.utexas.edu (Vax) writes: >Is it just me, or can someone just use stty to enable flow control on >the line? I thought that's what it is for. Yes, but getty(8) will restore the defaults and disable hw flow control when you log in. The problem is, you cannot configure 386BSDs' getty(8) to enable hw flow control. Setting the flow control with the minor device number lets you solve the problem for every application at once, you don't have to care about that anymore. >I think the preponderance of device files is a bit ugly, and it can eliminate >the usefulness of file locks in /var/lock/LCK..* You mix up two things. The device names `cua01' and `ttyd1' for the same device have nothing to do with the flow stuff. `cua0?' is the port for callouts (tip(1) or uucico(8)), `ttyd?' is for incoming calls (getty(8)). For more info read the doc for patch00163 in `/patch/INDEX-0.2.4'. All appls that have to use lock-files, those which call out, will use the `cua0?' device. So the two names are no problem. The reason why I ls'ed the devices was to show the changed minor device numbers. BTW my posted patch depended on COM_BIDIR being defined. Without `options COM_BIDIR' in the kernel config file recompiling `sio.c' wasn't possible. But that's easy to fix. Sorry, I will double check next time. -- Stefan (berry@max.IN-Berlin.DE)