From owner-svn-src-head@FreeBSD.ORG Thu Dec 19 17:24:22 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AC18C63; Thu, 19 Dec 2013 17:24:22 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C2111569; Thu, 19 Dec 2013 17:24:21 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rBJHOKGn041823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 09:24:21 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rBJHOKUL041822; Thu, 19 Dec 2013 09:24:20 -0800 (PST) (envelope-from jmg) Date: Thu, 19 Dec 2013 09:24:20 -0800 From: John-Mark Gurney To: Gleb Smirnoff Subject: Re: svn commit: r259562 - head/usr.bin/netstat Message-ID: <20131219172420.GS99167@funkthat.com> References: <201312181825.rBIIPR25014515@svn.freebsd.org> <20131218184512.GM99167@funkthat.com> <52B2009E.1060905@FreeBSD.org> <201312181640.52147.jhb@freebsd.org> <20131219115735.GN29088@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131219115735.GN29088@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 19 Dec 2013 09:24:21 -0800 (PST) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, "Alexander V. Chernikov" , John Baldwin X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:24:22 -0000 Gleb Smirnoff wrote this message on Thu, Dec 19, 2013 at 15:57 +0400: > On Wed, Dec 18, 2013 at 04:40:52PM -0500, John Baldwin wrote: > J> On Wednesday, December 18, 2013 3:07:58 pm Alexander V. Chernikov wrote: > J> > On 18.12.2013 22:45, John-Mark Gurney wrote: > J> > > Alexander V. Chernikov wrote this message on Wed, Dec 18, 2013 at 18:25 +0000: > J> > >> Author: melifaro > J> > >> Date: Wed Dec 18 18:25:27 2013 > J> > >> New Revision: 259562 > J> > >> URL: http://svnweb.freebsd.org/changeset/base/259562 > J> > >> > J> > >> Log: > J> > >> Switch netstat -rn to use standard API for retrieving list of routes > J> > >> instead of peeking inside in-kernel radix via kget. > J> > >> This permits us to change kernel structures without breaking userland. > J> > >> Additionally, this change provide more reliable and faster output. > J> > >> > J> > >> `Refs` and `Use` fields available in IPv4 by default (and via -W > J> > >> for other families) were removed. `Refs` is radix-specific thing > J> > >> which is not informative for users. `Use` field value is handy sometimes, > J> > >> but a) current API does not support it and b) I'm not sure we will > J> > >> support per-rte pcpu counters in near future. > J> > >> > J> > >> Old method of retrieving data is still supported (either by defining > J> > >> NewTree=0 or running netstat with -A). However, Refs/Use fields are > J> > >> hidden. > J> > >> > J> > >> Sponsored by: Yandex LLC > J> > >> MFC after: 4 weeks > J> > >> PR: kern/167204 > J> > > > J> > > How will this impact the use of netstat -rn -M vmcore -N kernel ? Will > J> > > this change make it not usable, or will you still automatically use > J> > Well. It will probably break in (maybe, near) future. > J> > J> Please don't gratuitiously break things that /usr/sbin/crashinfo runs. It's > J> fine if kvm mode is fragile and requires the binary to be in sync with the > J> kernel and is only used for crash dumps, but it is very useful to extract > J> all sorts of info out of a crash dump. > > The problem is that these tools (netstat, and some others) prevent us from > improving the kernel network stack. We can't make improvements that are > mergeable to stable/x branch, since the tools would be broken. Moreover > any improvement in head/, requires from developer additional work in netstat > code, which I must admit isn't a pleasure to work with. And any improvement > in head adds additional incompatibility between newer kernel and older world, > which is of course allowed in CURRENT, but still we'd prefer to reduce number > of such events. I've thought about this issue a bit, and I realized that w/ ctf (from dtrace) that we could make netstat and related tools be able to understand what fields are available, even w/ older/different kernels... It does mean we'd have to be careful not to repurpose struct names, but that shouldn't be too hard... I haven't been happy w/ reading raw structs, but w/ ctf, there would be "meaning" behind the data... We could even add a SYSCTL_ that prepends the data w/ the CTF data and the tool could support both methods... > I agree that usage of tools on vmcores is useful. But we all should agree that > it has very limited use. Only kernel hackers and developers are expected to > do this. However, speaking of myself, I was never interested in routing table > from a vmcore neither interface statistics, when fixing a bug in networking stack, > and I've fixed quite a lot of them. Still, I believe, that some developers find > this useful. > > My suggestion is that all this code is deleted from src/usr.bin/netstat, and > moved to src/tools, and we relax assertion that src/tools must be compatible > with any kernel within the branch. So, any person who wants this functionality, > needs to keep his src/tools in sync with kernel and compile a tool when he > desires to dump routing table from a vmcore. Having recently debugged a kernel issue, it was very nice that tools like dmesg could operate on a core... > Finally, when we remove all the kvm(3) usage from a tool, then we can remove > the sugid bit from it, which would be a another fine point. Which is a good thing, but shouldn't need to remove the kvm access.. We have dual kvm/sysctl access for most things in the kernel... Once a tool has completed sysctl access for all data it needs, why would it need the sgid bit? I will admit, I've never liked having dual access... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."