cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c uipc_syscalls.c src/usr.bin/netstat mbuf.c src/lib/libc/sys sendfile.2

[Robert Watson]

On Fri, 18 Jun 2004, Mike Silbersack wrote:

> In the case of adding output to netstat -m, what could possibly happen? 
> Maybe someone's mbuf monitoring script sets a false alarm - the user
> logs in to check the situation, finds out that sfbuf output was added,
> fixes the script, and life goes on. 

I actually thinks that our current statistics management model is weak
from the perspective of scripting regardless of this specific change.
sysctl generally offers a nice back-end way to script retrieval of
statistics; however, there are some statistics and post-processed results
that aren't available in an easily mechanically parsable form (almost any
output from systat, top, netstat, etc) because they're laid out for human
consumption, not script consumption.  Something I've been thinking about
for a bit is that we might consider adding a new flag to netstat (and
others) to cause the tools to generate more reasily parseable output.
I.e., in mib-like output:

test% netstat -mS
netstat.mbufs.current: 258
netstat.mbufs.peak: 1248
netstat.mbufs.max: 34176
netstat.mbufs.allocated_to_data: 258
netstat.mbuf_clusters.current: 256
...

This would allow new fields to be inserted easily without disturbing
highly usable output.  That way we can tweak the human layout forms with
impunity to take into account changes in requirements, changes in terminal
capabilities, etc, etc.  And it would make a lot easier when writing
scripts, because it would have predictable parsing without worry about
dealing with field truncation, odd hostnames, etc, etc.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research