Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Apr 2015 21:24:26 +0300
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r281188 - head/usr.bin/netstat
Message-ID:  <20150408182426.GT64665@FreeBSD.org>
In-Reply-To: <6969546.Tk7XnsGrVd@ralph.baldwin.cx>
References:  <201504070550.t375oklh014315@svn.freebsd.org> <6969546.Tk7XnsGrVd@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
  John,

On Wed, Apr 08, 2015 at 12:24:48PM -0400, John Baldwin wrote:
J> On Tuesday, April 07, 2015 05:50:46 AM Gleb Smirnoff wrote:
J> > Author: glebius
J> > Date: Tue Apr  7 05:50:45 2015
J> > New Revision: 281188
J> > URL: https://svnweb.freebsd.org/changeset/base/281188
J> > 
J> > Log:
J> >   Like it was already done for 'netstat -i', drop the kvm(3) support
J> >   in 'netstat -r'.
J> >   
J> >   The netstat/route.c was the last abuser of struct ifnet and struct
J> >   rtentry in the tree. With this change if_var.h can become kernel
J> >   only include, _WANT_RTENTRY can go away and projects/ifnet and
J> >   projects/routing can go forward.
J> >   
J> >   Differential Revision:	https://reviews.freebsd.org/D2242
J> >   Reviewed by:		melifaro, gnn
J> >   Sponsored by:		Nginx, Inc.
J> >   Sponsored by:		Netflix
J> 
J> This breaks netstat -r on a crashdump.  Just because you don't find this
J> information useful during post-mortem debugging doesn't mean that other folks
J> do not.  The easiest solution is to update crashinfo to remove the netstat
J> commands it runs.

I do analyze cores often, and always find gdb the only useful tool. My opinion
is seconded by melifaro@, who was quite a lot into the routing debugging for
the last years.

I will update crashinfo.

J> However, I don't understand the fear that system binaries can peek inside
J> the kernel for debugging info.  It's ok for it to be a fragile ABI that
J> isn't exposed to normal applications and to require people to keep a matching
J> netstat with their kernel (along with the other tools crashinfo calls).  Just
J> update the code in netstat to cope with the new data structures.  That should
J> be much easier to test than having to convert N device drivers.

You mentioned only the smallest problem - the need to routinely update
the netstat, as the fragile ABI changes.

But there are two more problems:

1) If userland application knows kernel structures, then we can not merge
to stable/X changes that change these structures. For example, since
netstat in stable/10 still uses kvm(3), we can't merge r256525 and r262763,
which improve performance and make counters precise. Yes, exactly the counters
that netstat is meant to report. We can't fix the netstat output due to netstat!

2) If we expose kernel structures to userland, people would write code that
use them. And the code won't go into src/tools only, it will also go into
ports. Albeit we have a stable API to read interface addresses and counters,
in the ports there were 15 applications, that were based on copy-paste from
netstat/if.c, using kvm(3) instead of API. And I had to fix them all.

Finally, when we start to expose kernel structures to userland this leads
to endless header dependencies, and may yield in expose all policy, but
usually yields in dirty hacks like hiding second half of a structure
under #ifdef _KERNEL.

-- 
Totus tuus, Glebius.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150408182426.GT64665>