Date: Tue, 3 Jun 2014 21:11:37 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John-Mark Gurney <jmg@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r266985 - head/sys/ddb Message-ID: <20140603193401.W1018@besplex.bde.org> In-Reply-To: <201406022350.s52NoJe1096873@svn.freebsd.org> References: <201406022350.s52NoJe1096873@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Jun 2014, John-Mark Gurney wrote:
> Log:
> handle longer commands so that lines don't overflow... people who added
> commands forgot to check this...
Please fix the sticky "." key on your keyboard. It keeps repeating
spuriously. Also the shift key.
The correct fix is to remove or rename the long commands.
> Modified: head/sys/ddb/db_command.c
> ==============================================================================
> --- head/sys/ddb/db_command.c Mon Jun 2 22:58:00 2014 (r266984)
> +++ head/sys/ddb/db_command.c Mon Jun 2 23:50:19 2014 (r266985)
> @@ -321,8 +321,8 @@ db_cmd_list(table)
> register struct command *cmd;
>
> LIST_FOREACH(cmd, table, next) {
> - db_printf("%-12s", cmd->name);
> - db_end_line(12);
> + db_printf("%-16s", cmd->name);
> + db_end_line(16);
> }
> }
12 is already too long. Who wants to type 11-15 character command
names? It would be better to punish long command name[r]s using
"%-11.11s " format (with complications to avoid the trailing space(s)
in the last column). This punishment is not very severe since command
names should be unique in the first character or 2. This is needed
anyway, to avoid typing long command names. The command name parser
supports this by matching the name typed with a possibly-longer name
in the table.
Expanding to 16 adds the following bugs:
- reduction in the number of fields on an 80 column terminal from 6 or 7
to 4 or 5 (from 6 * 12 + 7 or 8 left over depending on auto-wrap to
4 * 16 + 15 or 16 left over)
- different mishandling of autowrap. In -current, the handling seems to
be to always waste the last 16 columns (previously only 8). This
avoids problems with auto-wrap, but the change makes it waste many
more columns. The number of fields is now 4 (was 6). 6 * 13 would
fit just as well as 6 * 12 (except for terminals with between 73 and
78 columns). The formatting now works as follows:
The db_end_line()'s are not correctly paired with the db_printf()'s,
but they work. There is none before the first db_printf(), but callers
should arrange to start on a new line so there is no danger of
overruning the line before db_end_line() can check for overrun. Then
each db_end_line() except the last one (dynamically) is correctly paired
with the next db_printf(). Then the last db_end_line() checks for
output that will never be done. It may print a newline prematurely.
Perhaps an extra newline is printed to complete the table. This is
unclear because db_cmd_list() doesn't print one itself. I think
the prompt code _expects_ to be called with the previous line not
always terminated, and prints a newline iff necessary.
It used to give 7 fields of width 12 that were somehow usually
displayed nicely in 80 columns on a syscons terminal, depending
on whether the 12 characters printed in the 7 available columns
for the last field had enough trailing spaces. The trailing spaces
were apparently discarded by terminal magic on some terminals. But
command names of length exactly 8 gave auto-wrap problems, and ones
of length 9-12 were displayed in full and ran into the next line iff
they were in the 7th field. Command names of length 12 of course
ran into each other in any field except the last one.
Since command namers usually get things like this wrong, short names
should be enforced by panicing for long ones. I once fixed all sleep
message strings to fit in the available 6 characters, but neglected
to enforce this, so there are many more broken ones now. This bug is
now most common in the zfs and audit subsystems. From top output:
10 root -16 - 0K 16K audit_ 21 12:47 0.00% [audit]
6 root -8 - 0K 96K spa->s 5 0:30 0.00% [zfskern{trim zfreefall}]
6 root 20 - 0K 96K arc_re 10 0:20 0.00% [zfskern{arc_reclaim_thre}]
23 root -16 - 0K 16K sdflus 18 0:19 0.00% [softdepflush]
6 root -8 - 0K 96K l2arc_ 14 0:13 0.00% [zfskern{l2arc_feed_threa}]
670 auditdistd 20 0 23692K 3292K sigwai 11 0:04 0.00% auditdistd: [audit.ysv.FreeBSD.
8 root -16 - 0K 16K ipmire 0 0:00 0.00% [ipmi0: kcs]
The bad sleep messages are not even designed to be useful when truncated
to 6 characters, so for example almost the signal in audit_mumble is
truncated, but all the noise is kept. ipmire would be a good name for
mired ip but not for ipmi.
The bad sleep messages are mishandled differently in ps;
- in normal ps l output, MWCHAN is 6 wide
- but if any sleep message is longer than 6, MWCHAN is up to 8 wide. The
above subsystems still get their strings truncated, e.g. (ps lH output):
0 6 0 0 20 0 0 96 arc_recl DL - 0:20.04 [zfsk
0 6 0 0 -8 0 0 96 l2arc_fe DL - 0:13.24 [zfsk
0 6 0 0 -8 0 0 96 spa->spa DL - 0:29.53 [zfsk
0 6 0 0 -8 0 0 96 tx->tx_q DL - 0:05.60 [zfsk
0 6 0 0 -8 0 0 96 tx->tx_s DL - 62:10.01 [zfsk
0 10 0 0 -16 0 0 16 audit_wo DL - 12:47.10 [audi
78 670 669 0 20 0 23692 3292 sigwait SJ - 0:03.56 audit
Space that is not available is used to expand the MWCHAN field (and some
others), so the main command name is truncated almost into oblivion (just
4 columns for it, after wasting another one for "[").
- wide output format fixes the truncated main command name, but MWCHAN
remains truncated at 8:
0 6 0 0 20 0 0 96 arc_recl DL - 0:20.04 [zfskern/arc_reclaim]
0 6 0 0 -8 0 0 96 l2arc_fe DL - 0:13.24 [zfskern/l2arc_feed_]
0 6 0 0 -8 0 0 96 spa->spa DL - 0:29.53 [zfskern/trim zfreef]
0 6 0 0 -8 0 0 96 tx->tx_q DL - 0:05.60 [zfskern/txg_thread_]
0 6 0 0 -8 0 0 96 tx->tx_s DL - 62:10.58 [zfskern/txg_thread_]
0 10 0 0 -16 0 0 16 audit_wo DL - 12:47.20 [audit]
Actually, thread names are truncated by other mechanisms. Partly in the
kernel, so ps cannot recover.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140603193401.W1018>