From owner-svn-src-all@FreeBSD.ORG Wed Apr 8 18:24:32 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CB6719E; Wed, 8 Apr 2015 18:24:32 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83C37337; Wed, 8 Apr 2015 18:24:30 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t38IOQjE019673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2015 21:24:26 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t38IOQGS019672; Wed, 8 Apr 2015 21:24:26 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 8 Apr 2015 21:24:26 +0300 From: Gleb Smirnoff To: John Baldwin Subject: Re: svn commit: r281188 - head/usr.bin/netstat Message-ID: <20150408182426.GT64665@FreeBSD.org> References: <201504070550.t375oklh014315@svn.freebsd.org> <6969546.Tk7XnsGrVd@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6969546.Tk7XnsGrVd@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:24:32 -0000 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.