svn commit: r259562 - head/usr.bin/netstat

[John-Mark Gurney]

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."