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