svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[John Baldwin]

On Tuesday, March 21, 2017 11:50:04 AM Gleb Smirnoff wrote:
>   John,
> 
> On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
> J> First, this is a very good change and long overdue in divorcing the
> J> user-facing structure for live system reporting vs the kernel structure.
> J> 
> J> However, I realize you don't use info from netstat when debugging kernel
> J> crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
> J> require a matching kernel and thus require recompiling everytime the ABI
> J> changes, but it is useful to have them.  Please restore those.
> 
> I have very much anticipated this comment from you, John.
> 
> I would like to remind you, that we have had this very exact conversation
> back when I removed kvm support from netstat/route.c. Let me search the
> archives:
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> 
> This conversation has had a continuation on IRC, which I don't archive.
> 
> AFAIR, first I told that with all my involvement into networking stack,
> I never ever had experienced a need to run route stats on a core. The
> debugger were the only useful tool. And that opinion was seconded by
> other network hackers. Then we discussed that a proper tool chould use
> dynamic type parsing and not kvm(3). You said that future gdb has python
> scripting and that would work fine. Meanwhile, you insisted that I restore
> the functionality. I resisted to put kvm(3) back into netstat/route.c, and
> instead I created a gdb script that prints exactly what 'nestat -anr -M core'
> prints. And I committed the script just to satisfy your demand:
> 
> tools/debugscripts/netstat-anr.gdb
> 
> Can you please fairly answer, have you (or anyone else) ever used the
> script during these 2 years?

You never updated crashinfo to use the script (the point of crashinfo is to
give an automated bit of information users can include in bug reports).
crashinfo came from Yahoo! where knowing the active state of the system
during a crash was indeed useful.  It wasn't necessarily about debugging a
panic in the network stack, but about obtaining information about the system
useful in debugging crashes in arbitrary parts of the kernel.  I don't work
at Y! anymore, so I'm not in the same environment.  Those things tend to be
more useful when dealing with a large deployment of hetergenous systems
rather than doing focused development on a driver or a bunch of identical
systems with the same workload / role (e.g. appliances).

Also, the setgid thing is a red herring.  You don't need setgid to read from
a core, only to use kvm against a live system.  I'm all for using sysctls to
fetch data against live system and only keeping kvm for use with core dumps
which doesn't require setgid.

-- 
John Baldwin