Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.mail.uucp
Subject: Re: who has the line (was Re: Bidirectional Modem Lines ....)
Message-ID: <1453@auspex.auspex.com>
Date: 17 Apr 89 22:08:33 GMT
References: <1403@auspex.auspex.com> <492@lakart.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 30


 >> Huh?  Its sole purpose is to prevent two programs ("getty" and the
 >> program that's dialing out) from gaining simultaneous access to the same
 >> serial line.
 >
 >I thought tip / uucico did that when they opened the line.

"It", in this case, refers to the dialin/dialout feature. 
"tip"/"uucico" do *not* themselves do anything that keeps "getty" from
using the line; the serial port driver does so when the line is opened. 
("getty" is not running on the same major/minor as "tip" or "uucico", so
even if "tip" or "uucico" does a TIOCEXCL that won't stop "getty".)

 >Usually an idle getty looks like this:
 >
 >       F UID   PID  PPID CP PRI NI ADDR  SZ  RSS WCHAN  STAT TT  TIME COMMAND
 > 1800001   0  4872     1  0   3  0  5d8  40   28 cp_tty I    h1  0:00 - std.96
 >
 >where the cp_tty means it waiting for a tty to do something.

It's presumably waiting for carrier to come up on the serial port.

 >I'd do it now but I'm dialed in (catch 22 :-) ), but when uucico / tip
 >are running, the WCHAN changes to a 'u', and the stat goes to a 'S'
 >(short term snooze). So either uucico does some explicit widgetry to
 >nuke the getty, or the open does.

If you're talking about schemes of the sort used by SunOS, the "open"
does - it doesn't nuke the "getty", it just keeps the arrival of carrier
on the serial port from waking it up.