Xref: utzoo comp.bugs.sys5:648 comp.dcom.modems:2801
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!mailrus!cornell!uw-beaver!tektronix!percival!qiclab!sopwith!snoopy
From: snoopy@sopwith.UUCP (Snoopy T. Beagle)
Newsgroups: comp.bugs.sys5,comp.dcom.modems
Subject: Re: HDB uucico vs. uugetty
Summary: I think the bug is in your kernel
Message-ID: <35@sopwith.UUCP>
Date: 27 Oct 88 16:31:04 GMT
References: <489@redsox.UUCP>
Reply-To: snoopy@sopwith.UUCP (Snoopy T. Beagle)
Distribution: na
Organization: The Daisy Hill Puppy Farm
Lines: 43

In article <489@redsox.UUCP> campbell@sushi.UUCP (Larry Campbell) writes:
|OK, I give up.  I _cannot_ get uugetty to work.  Either I'm doing something
|very obscurely wrong, or HDB uucp is totally braindead.

|I'm running ISC 386/ix, which is SVR3, with HDB uucp.  I have two flavors of
|COM2 defined:  /dev/tty01, which has no modem control, and /dev/ttyM01,
|which has modem control.

|If I run uugetty on /dev/ttyM01, uugetty answers the phone OK, but uugetty
|and uucico trample each other, because uucico creates a lock file called
|LCK..tty01 while uugetty looks for LCK..ttyM01.  So uucico comes along and
|prods the modem awake, then the modem and uugetty scream at each other for a
|while, making the whole system very unhappy.

Sounds like the problem is in your kernel, rather than HDB.  Under the
scheme you are using, the device driver needs to prevent both tty01 and
ttyM01 from being opened at the same time.  Sounds like it isn't doing
that.  You might look through the documentation for the tty driver (tty(4)?)
and make sure you have the major/minor device numbers set up right and
all that. (sounds like you do, since your two /dev entries are accessing
the same port in two different ways, but it wouldn't hurt to look.)

I like my scheme better.  Instead of having two /dev entries for each device,
you supply a flag to the open call that says "I want to open this port
so I can talk to the modem, so open it if CD is *not* there." (If CD is
present, there is a call in progress, so *don't* open the device.)

This supplies the same functionality, without having to have a second
device entry cluttering up /dev ( causing slower directory searches, and
making directory listings even bigger, and quite likely confusing humans),
and with less work for the device driver to do (it doesn't have to insure
that both devices aren't opened at once, since there is only one device.
This allows less code in the kernel, and less potential for bugs. (like
the one it appears you have))

The cost in my scheme is that it uses up a bit in the open flag, and
you have to modify uucico and tip/cu to set this flag when opening the
device.
    _____     
   /_____\    Snoopy
  /_______\   
    |___|     tektronix!tekecs!sopwith!snoopy
    |___|     sun!nosun!illian!sopwith!snoopy