Date: Sun, 15 Jan 2017 13:07:58 +0800 From: Julian Elischer <julian@elischer.org> To: Mark Johnston <markj@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, rang@acm.org Subject: Re: svn commit: r311952 - head/sys/ddb Message-ID: <1755552c-a5e2-848a-38e2-3bacfbecfb23@elischer.org> In-Reply-To: <20170114220629.GB18065@raichu> References: <201701120022.v0C0MaHq053076@repo.freebsd.org> <20170113131948.P1465@besplex.bde.org> <20170114220629.GB18065@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>>
>> [...]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1755552c-a5e2-848a-38e2-3bacfbecfb23>