From owner-svn-src-all@freebsd.org Sun Jan 15 05:08:20 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98533CB0807; Sun, 15 Jan 2017 05:08:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EB001C13; Sun, 15 Jan 2017 05:08:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (ppp121-45-252-76.lns20.per4.internode.on.net [121.45.252.76]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v0F583ac018905 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 14 Jan 2017 21:08:06 -0800 (PST) (envelope-from julian@elischer.org) Subject: Re: svn commit: r311952 - head/sys/ddb To: Mark Johnston , Bruce Evans References: <201701120022.v0C0MaHq053076@repo.freebsd.org> <20170113131948.P1465@besplex.bde.org> <20170114220629.GB18065@raichu> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, rang@acm.org From: Julian Elischer Message-ID: <1755552c-a5e2-848a-38e2-3bacfbecfb23@elischer.org> Date: Sun, 15 Jan 2017 13:07:58 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170114220629.GB18065@raichu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 05:08:20 -0000 On 15/01/2017 6:06 AM, Mark Johnston wrote: > On Fri, Jan 13, 2017 at 02:51:04PM +1100, Bruce Evans wrote: >> On Thu, 12 Jan 2017, Mark Johnston wrote: >> >>> Log: >>> Enable the use of ^C and ^S/^Q in DDB. >>> >>> This lets one interrupt DDB's output, which is useful if paging is >>> disabled and the output device is slow. >> This is quite broken. It removes the code that was necessary for avoiding >> loss of input. > Hi Bruce, > > I've reverted this for now. I haven't thought much about how > db_check_interrupt() might losslessly poll the console driver for > ctrl-C, but I do think it's a valuable feature to have - just this > morning I absent-mindedly dumped a 128K-entry KTR ring from a DDB prompt > after having set $lines = 0, and had to wait for quite a while to get > my prompt back. > >>> Modified: head/sys/ddb/db_input.c >>> ============================================================================== >>> --- head/sys/ddb/db_input.c Thu Jan 12 00:09:31 2017 (r311951) >>> +++ head/sys/ddb/db_input.c Thu Jan 12 00:22:36 2017 (r311952) >>> @@ -63,7 +63,6 @@ static int db_lhist_nlines; >>> #define BLANK ' ' >>> #define BACKUP '\b' >>> >>> -static int cnmaygetc(void); >>> static void db_delete(int n, int bwd); >>> static int db_inputchar(int c); >>> static void db_putnchars(int c, int count); >>> @@ -291,12 +290,6 @@ db_inputchar(c) >>> return (0); >>> } >>> >>> -static int >>> -cnmaygetc() >>> -{ >>> - return (-1); >>> -} >>> - >> BSD never had a usable console API (function) for checking for input. >> cncheckc() is the correct name for such a function. The actual >> cncheckc() returns any input that it finds. This is not the main >> problem here. The input will have to be read here anyway to determine >> what it is. The problems are that there is no console API at all for >> ungetting characters in the input stream, and this function doesn't >> even use a stub cnungetc(), but drops the input on the floor. It does >> document this behaviour in a comment, but doesn't say that it is wrong. >> >>> int >>> db_readline(lstart, lsize) >>> char * lstart; >>> @@ -350,7 +343,7 @@ db_check_interrupt(void) >>> { >>> int c; >>> >>> - c = cnmaygetc(); >>> + c = cncheckc(); >>> switch (c) { >>> case -1: /* no character */ >>> return; >> The stub function always returns -1, so db_check_interrupt() is turned into >> a no-op. >> >> db_check_interrupt() now eats the first byte of any input on every call. >> >>> @@ -361,7 +354,7 @@ db_check_interrupt(void) >>> >>> case CTRL('s'): >>> do { >>> - c = cnmaygetc(); >>> + c = cncheckc(); >>> if (c == CTRL('c')) >>> db_error((char *)0); >>> } while (c != CTRL('q')); >> This is now a bad implementation of xon/xoff. It doesn't support ixany, >> but busy-waits for ^Q or ^C using cncheckc(). It should at least >> busy-wait using cngetc(), since that might be do a smarter busy wait. >> cngetc() is actually only slightly smarter -- it uses busy-waiting too, >> but with cpu_spinwait() in the loop. This cpu_spinwait() makes little >> difference since cncheckc() tends to be a heavyweight function. Only >> cpu_spinwait()s in the innermost loops of cncheckc(), if any, are likely >> to have much effect. >> >> Multiple consoles complicate this a bit. >> >> db_check_interrupt() is called after every db_putc() of a newline. So >> the breakage is mainly for type-ahead while writing many lines. > I'll note that type-ahead interacts rather poorly with DDB's behaviour > of repeating the previous command upon reading an empty input line: > entering a carriage return at any point while "show ktr" is working will > cause it to be started again once it's finished. the old DEC machines had (from memory) ^O which dropped all pending output. Not so useful when there is 2MB of network buffers queued up to you, but very useful on and asr-33 teletype. > >> Control processing belongs in the lowest level of console drivers, and >> at least the xon/xoff part is very easy to do. This makes it work for >> contexts like boot messages -- this can only be controlled now by booting >> with -p, which gives something like an automatic ^S after every line, >> but the control characters for this mode are unusual and there is no >> way to get back to -p mode after turning it off or not starting with it. >> >> [...]