Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Dec 1995 05:48:08 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        ache@astral.msk.su, bde@zeta.org.au, terry@lambert.org
Cc:        eugen@rd.zgik.zaporizhzhe.ua, hackers@FreeBSD.ORG, yura@rd.zgik.zaporizhzhe.ua
Subject:   Re: bug or feature in kern/tty.c
Message-ID:  <199512141848.FAA04916@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>>I.e.
>>1) driver needs to track carrier when in TS_ZOMBI and
>>set TS_CONNECTED, clear TS_ZOMBI when carrier
>>appearse on the line.

The driver tracks carrier in TS_CARR_ON and the modem hardware state
independent of CLOCAL and controlling terminalness.  TS_CARR_ON can't be
seen by normal processes but can be seen by snooping in kmem, e.g., by
pstat.  The driver is careful to NOT set TS_CONNECTED or clear TS_ZOMBIE
when carrier rises, since that would defeat the whole point of
TS_ZOMBIE, which is to stop the next call from being answered by the
current session if the session leader somehow survives the SIGHUP.

>>2) Slattach not need exit on SIGHUP but wait reasonable time
>>until carrier will be up again.

>I mean of course that CLOCAL turned on, i.e. slattach only
>controls line and establish carrier on them, not other
>program. So partial question is: is it possible to fix sio to send
>SIGHUP to controlling terminal even when CLOCAL is set?

No, for a SIGHUP to be sent, CLOCAL must be clear and the line must be
a controlling process.

slattach could simply poll for hangup like /usr/bin/sppp, e.g.,

	assert(not_a_controlling_terminal_here);
	for (;;) {
		int mstate;

		sleep(2);
		if (ioctl(fd, TIOCMGET, &mstate) != 0 || !(mstate & TIOCM_CD))
			break;
	}
	/*
	 * XXX in !CLOCAL mode, we would have to close and reopen the tty
	 * since POSIX says that the tty can't be used after the connection
	 * is broken.  This is inconvenient, and since we check carrier
	 * directly, we don't need !CLOCAL mode.
	 */
	assert(in_CLOCAL_mode);
	goto start;

except there is a race: the TIOCM_CD bit isn't sticky, so transient changes
of it might be missed.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512141848.FAA04916>