Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!news.sol.net!news.sol.net!not-for-mail From: jgreco@solaria.sol.net (Joe Greco) Newsgroups: comp.os.386bsd.bugs Subject: Re: PROBLEMS WITH FreeBSD Date: 3 Jan 1994 00:27:55 -0600 Organization: Solaria Public Access UNIX - Milwaukee, WI Lines: 65 Message-ID: <2g8dtb$b7c@solaria.mil.wi.us> References: <CIq8w7.7rM@csi.compuserve.com> <2g0kdl$2d9@cleese.apana.org.au> <2g2ere$esn@solaria.mil.wi.us> <2g4itv$fbu@wzv.win.tue.nl> NNTP-Posting-Host: solaria.mil.wi.us In comp.os.386bsd.bugs article <2g4itv$fbu@wzv.win.tue.nl>, guido@gvr.win.tue.nl (Guido van Rooij) wrote: :jgreco@solaria.sol.net (Joe Greco) writes: :>Now wait a minute. I thought the SIO drivers were supposed to provide :>bidirectional capability. How is this supposed to work? I've been looking :>for documentation for about a week, and have yet to find anything. :Only when you make them bidirectional. Use comcontrol <device> bidir to :tuen on or ,, ,, -bidir to turn of. I had actually done that, and was getting an ioctl error of some sort... :>Under SunOS, which IMHO has a "reasonable" bidirectional mechanism, open() :>will block on the opening of a terminal device unless there is carrier AND :>the port is not already open in the other direction (cua0 or whatever). :>cua0 can be opened regardless of the state of carrier, unless the port is :>already open in the other direction (tty00 or whatever). This allows getty :>to hang on tty00, and uucp/kermit/tip/cu to call out on cua0, transparently. :This indeed is the way sio works in bidir mode. But you dont want bidir :capabilities for a hard wired terminal...do you? And then when you have a :hard wired terminal, you have to make sure that the wiring is correct. If you have a hard wired terminal, you don't particularly care if there are bidir capabilities, you simply don't do stupid things like accessing the outgoing device. :>Ideally, I'd _love_ to see this done with SIO, and I was actually under the :>impression that SIO had a direct analogy of some sort. :Indeed it has so. And I agree that there should be documentation on this. Actually, what should be documented is what follows... :>Setting clocal or locking DCD in some manner could make all of this rather :>difficult, if it works at all like any other implementation I've seen. So :>what's the deal? Does SIO provide bidirectional capabilities? And if so, :>what is the technique used to implement (and/or use) it? :You would only set clocal for hardwired terminals. In the bidirectional :case, clocal would result in the getty not blocking on open. Yes (although I tend to build cables so I don't have to play with this kind of stuff - I lock DCD and other signals in my cables, and I can exchange a terminal for a modem, if I so desire). I finally got exasperated one day because I needed the bidirectional capabilities. I couldn't find a man page on comcontrol, putzed around trying a few different likely possibilities with mknod trying to generate a "cua0", and then got desperate enough to load kernel sources onto the machine. I was a tad exasperated when I saw the first few lines in sio.c, and a lot more irritated by the omission of "COM_BIDIR" in GENERICAH. This seems like a pointless and unfortunate kernel omission, unless there is some disadvantage to COM_BIDIR that I am overlooking. Anyways, that solves the mystery of bidirectional ports to my satisfaction. Perhaps somebody could put this in the FreeBSD FAQ (if it's not already), and then perhaps post the FAQ someplace easy to find, like on freebsd.cdrom.com in the FreeBSD directories? :-) :-) I spent 30 minutes looking for the FAQ in the process of trying to solve the bidir stuff, and I never did find it. Happy New Year, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847