Date: Thu, 19 Dec 2013 09:24:20 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, "Alexander V. Chernikov" <melifaro@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org> Subject: Re: svn commit: r259562 - head/usr.bin/netstat Message-ID: <20131219172420.GS99167@funkthat.com> In-Reply-To: <20131219115735.GN29088@FreeBSD.org> References: <201312181825.rBIIPR25014515@svn.freebsd.org> <20131218184512.GM99167@funkthat.com> <52B2009E.1060905@FreeBSD.org> <201312181640.52147.jhb@freebsd.org> <20131219115735.GN29088@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131219172420.GS99167>