Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!darwin.sura.net!wupost!uunet!pipex!ibmpcug!exnet!exnet2!flatlin!bad
From: bad@flatlin.ka.sub.org (Christoph Badura)
Subject: Re: uugetty for 386bsd
Organization: Guru Systems/Funware Department
Date: Sun, 25 Oct 1992 15:02:40 GMT
Message-ID: <Bwon4H.Lx8@flatlin.ka.sub.org>
References: <x-vpr1n_@aix01.rz.fht-mannheim.de> <1992Oct18.191610.1992@draco.bison.mb.ca> <1992Oct20.174948.742@fcom.cc.utah.edu>
Lines: 93
In <1992Oct20.174948.742@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>The purpose of uugetty is twofold:
>1) It waits for a return before spitting anything back; thus an
> improperly configured modem will continue to operate.
>2) It allows bidirectional use of modems.
You have it backwards.
The primary purpose of uugetty in *HDB* UUCP is to allow the use of
bidrectional modem lines *despite* the lack of properly interlocking
tty drivers. This is the reason why the uucp device lock files are
created.
Further, uugetty *only* waits for a return before spitting anything
back, iff it is called with the -r option. This is solely to prevent
two uugettys locking up by spitting login:s at each other on direct
lines.
>Additionally, I object to uugetty's creation of UUCP style lockfiles.
Why? Because they are not needed with properly interlocking tty
drivers? Or because HDB has to cope with all sorts of tty braindamage,
like say not properly interlocking tty drivers, on the various
platforms it runs on?
> HDB
>UUCP and clones do not correctly use the exclusivity mechanism from
>O_EXCL, which should be sufficient to this task. The existance of these
>lock files appears to be the result of a misunderstanding of what is
>called "the partial open hack" in sys2.c in the original SVR3.2 kernel;
>this is probably because "open order" was not understood with reference
>to O_EXCL not being reset on an O_NDELAY open --
What are you talking about. sys2.c knows zilch about O_NDELAY and
O_EXCL.
> in actuality, a SVR3.2
>UNIX will not reset and of the tty struct contents in the case of O_NDELAY.
>This was either intentional (unlikely), or the result of misplacing about
>12 lines of code in the dup2() system call implementation code, which is
>also used during a "partial open hack" operation.
Again, what are you talking about?
SVR3 never reset the tty struct contents. It has always been the tty
drivers calling ttinit() to do so. And since the tty struct (and
ttinit() for that matter) know zilch about interlocking drivers,
O_EXCL, and O_NDELAY how could it possibly be done with the tty
struct?
And the dup2() system call has nothing to do with that either, because
SVR3 doesn't support dup2() anyway. dup2() doesn't deal with
"half-open" file descriptors, it doesn't deal with copen()/copen1() in
any way.
>In any case, Berkeley style calling units obviate the problem.
Indeed.
> One of the major problems in
> the SCO implementation is the confusion of having two
> devices, both of which may operate simultaneously. Thus
> the call-out works, but on connection a local host "login:"
> is echoed down the line to the remote host. This is an
> error. Login should only be enabled on the "non calling
> unit" device.
Huh? I have never seen that one and I run SCO.
> d) Flags information should not be shared between versions of
> the device ("calling unit" vs. "non calling unit"), but
> mode information should be. Thus baud rate is common, but
> O_EXCL and O_NDELAY are not.
Give me a good reason why I shouldn't be able to have a 19200,8,N,1
getty hanging on the dialin device while dialing out with 9600,7,e,2.
> Note that this requires
> blocking O_NDELAY opens to the device when its counterpart
> is in use. This is acceptable, as it allows proper fail
> out on multiple getty's on the same device.
I don't see a need for blocking a non-blocking open. Maybe it's
because I don't understand what you want this for. An example why a
non-blocking open shouldn't return EBUSY when the device's couterpart
is in use would be most helpfull.
--
Christoph Badura --- bad@flatlin.ka.sub.org
AIX is a better... is a better... is a better... OpenSystem.
IBM Rep at GUUG Symposium '92