Date: Fri, 18 Jun 2004 09:31:02 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Mike Silbersack <silby@silby.com> Cc: Max Khon <fjoe@samodelkin.net> Subject: Re: 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 Message-ID: <Pine.NEB.3.96L.1040618092515.71584A-100000@fledge.watson.org> In-Reply-To: <20040618014912.O72823@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040618092515.71584A-100000>