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."
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
