Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!utah-morgan!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Using the sio ports with a Modem Message-ID: <1993Aug9.213957.18706@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <1993Aug3.051002.2690@fcom.cc.utah.edu> <241bn9INNemm@kralizec.zeta.org.au> <CBHLwJ.737@flatlin.ka.sub.org> Date: Mon, 9 Aug 93 21:39:57 GMT Lines: 52 In article <CBHLwJ.737@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes: >In <241bn9INNemm@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes: > >>This is the only really interesting/complicated/broken case. Again I >>think you have -clocal back to front. The problem here is the opposite. >>CLOCAL needs to be kept off, but dialout programs might turn it on. >>If the forget to turn it back off when they exit, then gettys on the >>dialin port will be adversely affected. > >I think you guys implicitly assume that a dial-in and its >corresponding dial-out device must share the same tty structure in the >driver. That need not be the case. In fact, separating the tty >structures simplifies matters and nicely solves the problem of >restoring the tty state on the dial-in device after the dial-out >device has been used. Oh no, just the opposite! But seperation can't be the only way to solve the problem, since that immediately orphans a lot of multiport cards. For instance, it's possible to use an Arnet 8-port board with the same download binary as for Xenix if one does not make the assumption the the tty struct must be divorced and two must be shared. I'm not saying that splitting shouldn't be an implementation option where possible (like with dumb cards), only that the behavioural definition had better not require it in cases where it may be impossible! Getting a correct state machine definition for the drivers and a correct state-predicated usage model is a necessary first step, followed by the implementation. A state model requiring splitting and seperate maintenance of state for the calling unit and tty unit of a device *dictates* implementation; it's a broken model because it disallows some really useful (and preexisting) models for smart boards, and because it is at odds with existing practice; we should not bite off on unnecessary maintenance because we have a "better" way of doing things (or we'd end up without any uucp lock files at all and a rewrite of the system interface portions of uucp). Remember, further, that network pseudo-devices used for modem pooling won't be able to handle the split model either (and *will* require templating to allow for a known state after DCD drop). We should, at the very least, take Sun's (or some other) UCB model, and at the very most, we should support both UCB and SVR4 behaviours in a split device model (per UCB). The current implementation is inconsistant with any of these. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.