Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hao!seismo!rlgvax!cvl!umcp-cs!chris
From: chris@umcp-cs.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Getting 'getty' to hangup dialup lines.
Message-ID: <8096@umcp-cs.UUCP>
Date: Fri, 10-Aug-84 22:47:15 EDT
Article-I.D.: umcp-cs.8096
Posted: Fri Aug 10 22:47:15 1984
Date-Received: Mon, 13-Aug-84 00:42:27 EDT
References: <297@ipms.UUCP> <2479@mit-eddie.UUCP> <2927@watcgl.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 17

I've been thinking about changing the vhangup system call to switch the
file descriptor over to an inode to /dev/null.  Here's my idea:  have
init call vhangup with a file descriptor that is open on /dev/null.
Have vhangup switch the inode given by the file pointer connected to
the terminal in question and the inode given by the file pointer given
to the vhangup system call.  Some fiddling with f_counts would need to
be done, of course, if multiple instances of the hung-up terminal are
lying around.  Finally, when the vhangup returns, init can just close()
the file descriptor, which will either point to /dev/null (no instances
of the hung-up terminal found) or to the terminal being hung-up.

Does anyone know of any potential problems with this (aside from init
compatibility issues)?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland