Date: Mon, 29 Jan 1996 13:21:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dennis@etinc.com (dennis) Cc: hm@altona.hamburg.com, hackers@FreeBSD.org Subject: Re: Multi-Port Async Cardsy Message-ID: <199601292021.NAA04335@phaeton.artisoft.com> In-Reply-To: <199601271740.MAA07892@etinc.com> from "dennis" at Jan 27, 96 12:40:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Finally someone in the company i'm working for put an ancient AST "Cluster > >Controller" on my desk, 4 full modem ports equipped with 8250's and just > >one IRQ needed. AST Germany was VERY helpful in getting the dip switch > >settings for this ancient board, it is fully supported by sio and it runs > >without any problems - i'm fully satisfied. > > This scenario is frightening to me....although I think that you've > answered my question......Its the final straw I think in making > FreeBSD marketable...obviously the AST solution is unacceptable for > a real ISP....I wonder why the cyclades board needs mgetty.....whats > the major diff between getty and mgetty? Dennis, you are silly. 8-). The Cyclades board needs mgetty if you run the third party driver because that driver doesn't do the calling unit interlock necessary to make it work bidirectionally using the BSD standard methods. The difference between getty and mgetty is that getty hangs on open pending DCD and mgetty does the open without waiting and reads modem result codes. Really, mgetty wants to be implemented with an open hang pending an RI signal, but not everyone implements RI correctly (namely Apple and NeXT 8 pin din is one pin shy of full modem control and two pins shy of full modem control with RI). Minimum is 9 pins w/o chassis ground. Mgetty also "respects" (quoted because it does the open and sits in select() and isn't quite right because it should check after select comes true, not after the read after select comes true) lock files. So if your outgoing software does port locking using correct (UUCP) lock files, then mgetty will eat some data from the modem (usually result codes from the first dial attempt) then it will back out of the way of the program calling out (if one dial failure can be said to be "out of the way"). Really, you want 3 ports, a modified driver, and an mgetty like program that doesn't do getty stuff itself, instead only multiplexing the port to multiple destinations based on the modem result codes (fax/modem/voice). No one has modified the driver, built the mux, or written the program yet, since you can limp along with mgetty at only minor inconvenience. If anyone wants to get into a full on design discussion, we should take it off the list, since it's already been discussed several times. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601292021.NAA04335>