Return to BSD News archive
Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!xlink.net!subnet.sub.net!flatlin!bad
From: bad@flatlin.ka.sub.org (Christoph Badura)
Subject: Re: Using the sio ports with a Modem
Organization: Guru Systems/Funware Department
Date: Sat, 14 Aug 1993 00:58:04 GMT
Message-ID: <CBq5Ct.6LH@flatlin.ka.sub.org>
References: <1993Aug3.051002.2690@fcom.cc.utah.edu> <241bn9INNemm@kralizec.zeta.org.au> <CBHLwJ.737@flatlin.ka.sub.org> <1993Aug9.213957.18706@fcom.cc.utah.edu>
Lines: 73
In <1993Aug9.213957.18706@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>In article <CBHLwJ.737@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:
>>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!
The opposite to what? That it solves the problem of restoring the tty
state?
> 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.
That's a broad claim, Terry, and I would like to hear a technical
reason why you think this is so. I've been thinking about that issue
the whole week and can't find one.
>A state model requiring splitting and seperate maintenance of state for
>the calling unit and tty unit of a device *dictates* implementation;
So does a model that requires sharing of state. What's your point?
> 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;
Using separate tty structs for *dumb* serial boards in no way forces
you to use the same model for smart boards. I don't see the relevance
of your argument.
It's also not at odds with existing practice. In fact, it works
rather well. It works so well that lots of sites dropped AT&T's
non-functional "existing practice" and switched to FAS. After all,
that was one of the reasons why FAS was developed.
Further, your "existing practice" requires such hacks like uugetty
busy waiting when a process is using its port for dial-out, or worse,
requiring that an application that wants to use a dial-in port for
dial-out to disable the getty and reenable it when it's done (which it
may not be able to, because it missed to catch a signal).
>we should not bite off on unnecessary maintenance because we have a "better"
>way of doing things
A working driver beats defunct "existing practice" any day.
>Remember, further,
>that network pseudo-devices used for modem pooling won't be able to
>handle the split model either
I don't recall that you've mentioned that fact before. Maybe you want
to explain to us *why* that is so.
> (and *will* require templating to allow for
>a known state after DCD drop).
I wonder what this mysterious "templating" that you're constantly
referring to *really* means. How about giving us a complete
specification?
--
Christoph Badura --- bad@flatlin.ka.sub.org --- +49 721 606137
Personally, I don't care whether someone is cool enough to quote Doug
Gwyn--I only care whether Doug Gwyn is cool enough to quote. -- Larry Wall