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.

[...]


_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to