Date: Mon, 1 May 2000 21:22:09 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Andrey A. Chernov" <ache@FreeBSD.ORG> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern tty.c Message-ID: <Pine.BSF.4.21.0005012049530.3898-100000@alphplex.bde.org> In-Reply-To: <20000430112344.A13987@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Apr 2000, Andrey A. Chernov wrote: > On Mon, May 01, 2000 at 04:11:56AM +1000, Bruce Evans wrote: > > This is all very broken. It used to be possible to set the drainwait timeout > > using comcontrol and have the setting live across closes. /etc/rc.serial > > has examples of setting it. Now, the setting gets clobbered in ttyopen() > > BTW, you say nothing when I send initial patch for review. I was too busy to review it before you committed it, and didn't notice the main problem with it. > Probably ttyopen not the best place for setting t_timeout to its default value. > What place you suggest as better one? At device creation time, much like where you put it. > > Sysctls shouldn't be used in device drivers. Here the default should only > > be used if the timeout has not already been set. Changing the default > > using sysctl will have little or no effect effect after the system has > > warmed up, since most or all ttys will have had their timeouts set. > > I disagree. > 1) This sysctl supposed to be called early in rc.sysctl, before any tty device > comes up. I wasn't sure about the ordering. In any case, the console will be up then, and maybe some other devices (e.g., ones you have used in single-user mode). It's only slightly harder to set the timeout for all tty devices than for one. > 2) You forget about ptys which are open/closed often, it is needed mainly for > them (hanging TCP connections) I didn't completely forget. I didn't notice the problem with dynamically created ptys. A loop to set all ptys would bogotify the dynamism by creating them all. I think the correct for all of this is for the timeout to only apply during exit(). If the close is under process control, then the process should be responsible for timing it out, and if the process is buggy then you can kill it. In exit(), we know that the process didn't care very much about the data being written, so we can use a small timeout (say twice the normal output time at the current line speed, or a second or two for ptys). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005012049530.3898-100000>