Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[John Baldwin]

On Friday, March 24, 2017 10:45:09 AM Gleb Smirnoff wrote:
>   John,
> 
> On Tue, Mar 21, 2017 at 02:24:30PM -0700, John Baldwin wrote:
> J> > I have very much anticipated this comment from you, John.
> J> > 
> J> > I would like to remind you, that we have had this very exact conversation
> J> > back when I removed kvm support from netstat/route.c. Let me search the
> J> > archives:
> J> > 
> J> > https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> J> > 
> J> > This conversation has had a continuation on IRC, which I don't archive.
> J> > 
> J> > AFAIR, first I told that with all my involvement into networking stack,
> J> > I never ever had experienced a need to run route stats on a core. The
> J> > debugger were the only useful tool. And that opinion was seconded by
> J> > other network hackers. Then we discussed that a proper tool chould use
> J> > dynamic type parsing and not kvm(3). You said that future gdb has python
> J> > scripting and that would work fine. Meanwhile, you insisted that I 
> restore
> J> > the functionality. I resisted to put kvm(3) back into netstat/route.c, 
> and
> J> > instead I created a gdb script that prints exactly what 'nestat -anr -M 
> core'
> J> > prints. And I committed the script just to satisfy your demand:
> J> > 
> J> > tools/debugscripts/netstat-anr.gdb
> J> > 
> J> > Can you please fairly answer, have you (or anyone else) ever used the
> J> > script during these 2 years?
> J> 
> J> You never updated crashinfo to use the script (the point of crashinfo is to
> J> give an automated bit of information users can include in bug reports).
> J> crashinfo came from Yahoo! where knowing the active state of the system
> J> during a crash was indeed useful.  It wasn't necessarily about debugging a
> J> panic in the network stack, but about obtaining information about the 
> system
> J> useful in debugging crashes in arbitrary parts of the kernel.  I don't work
> J> at Y! anymore, so I'm not in the same environment.  Those things tend to be
> J> more useful when dealing with a large deployment of hetergenous systems
> J> rather than doing focused development on a driver or a bunch of identical
> J> systems with the same workload / role (e.g. appliances).
> 
> Since you outlined that it is important that systems are heterogenous, looks
> like you anticipated my reply that at Netflix we also do automated crash
> collection. :)
> 
> Still, my personal experience is that when analyzing a crash, you aren't
> interested in full table, be it a routing table or a PCB list. You are
> focused on the entry that crashed. This experience comes from my previous
> job Rambler, which is a Russian version of Yahoo! :)
> All the time I analyzed our internal crashes, or FreeBSD PRs, I always
> PgDown-ed this tons of information.

I'm not saying it is always useful, but it is sometimes useful.  And it may
not be a panic in the network stack, but more "which connections and on which
mix of ports were active when it crashed".  'ps' output isn't only useful
when you have a crash in fork().  It happens to be useful for other types of
panics as well.
 
> J> Also, the setgid thing is a red herring.  You don't need setgid to read 
> from
> J> a core, only to use kvm against a live system.  I'm all for using sysctls 
> to
> J> fetch data against live system and only keeping kvm for use with core dumps
> J> which doesn't require setgid.
> 
> Which means that if you want a tool to print out stats from a core, that 
> should
> be a separate tool. And the runtime tool netstat should get free of kvm, and 
> of
> setgid bit.

A separate tool means that you have to reproduce the formatting bits, and it
is convenient to have consistent output.
 
> Here we again come to the need of debugger with better scripting support. What
> are the expectations for newer gdb which has python scripting?

'pkg install gdb' has provided a working kgdb for over a year now.  crashinfo
will even look for and prefer kgdb from ports over kgdb from base.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Gleb Smirnoff]

  John,

On Tue, Mar 21, 2017 at 02:24:30PM -0700, John Baldwin wrote:
J> > I have very much anticipated this comment from you, John.
J> > 
J> > I would like to remind you, that we have had this very exact conversation
J> > back when I removed kvm support from netstat/route.c. Let me search the
J> > archives:
J> > 
J> > https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
J> > 
J> > This conversation has had a continuation on IRC, which I don't archive.
J> > 
J> > AFAIR, first I told that with all my involvement into networking stack,
J> > I never ever had experienced a need to run route stats on a core. The
J> > debugger were the only useful tool. And that opinion was seconded by
J> > other network hackers. Then we discussed that a proper tool chould use
J> > dynamic type parsing and not kvm(3). You said that future gdb has python
J> > scripting and that would work fine. Meanwhile, you insisted that I restore
J> > the functionality. I resisted to put kvm(3) back into netstat/route.c, and
J> > instead I created a gdb script that prints exactly what 'nestat -anr -M 
core'
J> > prints. And I committed the script just to satisfy your demand:
J> > 
J> > tools/debugscripts/netstat-anr.gdb
J> > 
J> > Can you please fairly answer, have you (or anyone else) ever used the
J> > script during these 2 years?
J> 
J> You never updated crashinfo to use the script (the point of crashinfo is to
J> give an automated bit of information users can include in bug reports).
J> crashinfo came from Yahoo! where knowing the active state of the system
J> during a crash was indeed useful.  It wasn't necessarily about debugging a
J> panic in the network stack, but about obtaining information about the system
J> useful in debugging crashes in arbitrary parts of the kernel.  I don't work
J> at Y! anymore, so I'm not in the same environment.  Those things tend to be
J> more useful when dealing with a large deployment of hetergenous systems
J> rather than doing focused development on a driver or a bunch of identical
J> systems with the same workload / role (e.g. appliances).

Since you outlined that it is important that systems are heterogenous, looks
like you anticipated my reply that at Netflix we also do automated crash
collection. :)

Still, my personal experience is that when analyzing a crash, you aren't
interested in full table, be it a routing table or a PCB list. You are
focused on the entry that crashed. This experience comes from my previous
job Rambler, which is a Russian version of Yahoo! :)
All the time I analyzed our internal crashes, or FreeBSD PRs, I always
PgDown-ed this tons of information.

J> Also, the setgid thing is a red herring.  You don't need setgid to read from
J> a core, only to use kvm against a live system.  I'm all for using sysctls to
J> fetch data against live system and only keeping kvm for use with core dumps
J> which doesn't require setgid.

Which means that if you want a tool to print out stats from a core, that should
be a separate tool. And the runtime tool netstat should get free of kvm, and of
setgid bit.

Here we again come to the need of debugger with better scripting support. What
are the expectations for newer gdb which has python scripting?

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[John Baldwin]

On Tuesday, March 21, 2017 11:50:04 AM Gleb Smirnoff wrote:
>   John,
> 
> On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
> J> First, this is a very good change and long overdue in divorcing the
> J> user-facing structure for live system reporting vs the kernel structure.
> J> 
> J> However, I realize you don't use info from netstat when debugging kernel
> J> crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
> J> require a matching kernel and thus require recompiling everytime the ABI
> J> changes, but it is useful to have them.  Please restore those.
> 
> I have very much anticipated this comment from you, John.
> 
> I would like to remind you, that we have had this very exact conversation
> back when I removed kvm support from netstat/route.c. Let me search the
> archives:
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> 
> This conversation has had a continuation on IRC, which I don't archive.
> 
> AFAIR, first I told that with all my involvement into networking stack,
> I never ever had experienced a need to run route stats on a core. The
> debugger were the only useful tool. And that opinion was seconded by
> other network hackers. Then we discussed that a proper tool chould use
> dynamic type parsing and not kvm(3). You said that future gdb has python
> scripting and that would work fine. Meanwhile, you insisted that I restore
> the functionality. I resisted to put kvm(3) back into netstat/route.c, and
> instead I created a gdb script that prints exactly what 'nestat -anr -M core'
> prints. And I committed the script just to satisfy your demand:
> 
> tools/debugscripts/netstat-anr.gdb
> 
> Can you please fairly answer, have you (or anyone else) ever used the
> script during these 2 years?

You never updated crashinfo to use the script (the point of crashinfo is to
give an automated bit of information users can include in bug reports).
crashinfo came from Yahoo! where knowing the active state of the system
during a crash was indeed useful.  It wasn't necessarily about debugging a
panic in the network stack, but about obtaining information about the system
useful in debugging crashes in arbitrary parts of the kernel.  I don't work
at Y! anymore, so I'm not in the same environment.  Those things tend to be
more useful when dealing with a large deployment of hetergenous systems
rather than doing focused development on a driver or a bunch of identical
systems with the same workload / role (e.g. appliances).

Also, the setgid thing is a red herring.  You don't need setgid to read from
a core, only to use kvm against a live system.  I'm all for using sysctls to
fetch data against live system and only keeping kvm for use with core dumps
which doesn't require setgid.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Slawa Olhovchenkov]

On Tue, Mar 21, 2017 at 01:40:22PM -0700, Gleb Smirnoff wrote:

> On Tue, Mar 21, 2017 at 10:52:02PM +0300, Slawa Olhovchenkov wrote:
> S> > On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
> S> > J> First, this is a very good change and long overdue in divorcing the
> S> > J> user-facing structure for live system reporting vs the kernel 
> structure.
> S> > J> 
> S> > J> However, I realize you don't use info from netstat when debugging 
> kernel
> S> > J> crash dumps, but other people _do_.  It's ok if the kvm bits of 
> netstat
> S> > J> require a matching kernel and thus require recompiling everytime the 
> ABI
> S> > J> changes, but it is useful to have them.  Please restore those.
> S> > 
> S> > I have very much anticipated this comment from you, John.
> S> > 
> S> > I would like to remind you, that we have had this very exact conversation
> S> > back when I removed kvm support from netstat/route.c. Let me search the
> S> > archives:
> S> > 
> S> > https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> S> > 
> S> > This conversation has had a continuation on IRC, which I don't archive.
> S> > 
> S> > AFAIR, first I told that with all my involvement into networking stack,
> S> > I never ever had experienced a need to run route stats on a core. The
> S> > debugger were the only useful tool. And that opinion was seconded by
> S> > other network hackers. Then we discussed that a proper tool chould use
> S> > dynamic type parsing and not kvm(3). You said that future gdb has python
> S> > scripting and that would work fine. Meanwhile, you insisted that I 
> restore
> S> > the functionality. I resisted to put kvm(3) back into netstat/route.c, 
> and
> S> > instead I created a gdb script that prints exactly what 'nestat -anr -M 
> core'
> S> > prints. And I committed the script just to satisfy your demand:
> S> > 
> S> > tools/debugscripts/netstat-anr.gdb
> S> > 
> S> > Can you please fairly answer, have you (or anyone else) ever used the
> S> > script during these 2 years?
> S> > 
> S> > I believe, the inpcb/tcpcb printing from a core functionality has the
> S> > same level of real usefulness. I could create the same script for pcbs,
> S> > and I am afraid it is going to share fate of netstat-anr.gdb.
> S> 
> S> How long run this script for core file w/ 40K TCP connections?
> 
> You tell me. When I analyze cores, I don't read through 40K TCP connections.

Real, frech core:

# grep netstat /var/crash/core.txt.3
netstat -s
netstat -m
netstat: memstat_kvm_all: invalid address (0x0)
netstat -anA
netstat -aL
# grep -c tcp4 /var/crash/core.txt.3
38172

This created automaticly at reboot and boot paused until core.txt
created.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Gleb Smirnoff]

On Tue, Mar 21, 2017 at 10:52:02PM +0300, Slawa Olhovchenkov wrote:
S> > On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
S> > J> First, this is a very good change and long overdue in divorcing the
S> > J> user-facing structure for live system reporting vs the kernel structure.
S> > J> 
S> > J> However, I realize you don't use info from netstat when debugging kernel
S> > J> crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
S> > J> require a matching kernel and thus require recompiling everytime the ABI
S> > J> changes, but it is useful to have them.  Please restore those.
S> > 
S> > I have very much anticipated this comment from you, John.
S> > 
S> > I would like to remind you, that we have had this very exact conversation
S> > back when I removed kvm support from netstat/route.c. Let me search the
S> > archives:
S> > 
S> > https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
S> > 
S> > This conversation has had a continuation on IRC, which I don't archive.
S> > 
S> > AFAIR, first I told that with all my involvement into networking stack,
S> > I never ever had experienced a need to run route stats on a core. The
S> > debugger were the only useful tool. And that opinion was seconded by
S> > other network hackers. Then we discussed that a proper tool chould use
S> > dynamic type parsing and not kvm(3). You said that future gdb has python
S> > scripting and that would work fine. Meanwhile, you insisted that I restore
S> > the functionality. I resisted to put kvm(3) back into netstat/route.c, and
S> > instead I created a gdb script that prints exactly what 'nestat -anr -M 
core'
S> > prints. And I committed the script just to satisfy your demand:
S> > 
S> > tools/debugscripts/netstat-anr.gdb
S> > 
S> > Can you please fairly answer, have you (or anyone else) ever used the
S> > script during these 2 years?
S> > 
S> > I believe, the inpcb/tcpcb printing from a core functionality has the
S> > same level of real usefulness. I could create the same script for pcbs,
S> > and I am afraid it is going to share fate of netstat-anr.gdb.
S> 
S> How long run this script for core file w/ 40K TCP connections?

You tell me. When I analyze cores, I don't read through 40K TCP connections.

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Ngie Cooper (yaneurabeya)]

> On Mar 21, 2017, at 13:07, Cy Schubert  wrote:

…

> Would it be possible to replace this script with new DTrace probes and a
> DTrace script?

I don’t genuinely think that using DTrace probes on a kernel coredump 
would work today, and even if it did, I don’t think it would make sense (DTrace 
-> Dynamic Trace). What gjb/jhb are discussing is post-mortem analysis of a 
coredump (netstat uses sysctl(3) to query the routing socket on live kernels).
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Slawa Olhovchenkov]

On Tue, Mar 21, 2017 at 01:07:42PM -0700, Cy Schubert wrote:

> In message <20170321195202.gf86...@zxy.spb.ru>, Slawa Olhovchenkov writes:
> > On Tue, Mar 21, 2017 at 11:50:04AM -0700, Gleb Smirnoff wrote:
> > 
> > >   John,
> > > 
> > > On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
> > > J> First, this is a very good change and long overdue in divorcing the
> > > J> user-facing structure for live system reporting vs the kernel 
> > > structure.
> > > J> 
> > > J> However, I realize you don't use info from netstat when debugging 
> > > kernel
> > > J> crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
> > > J> require a matching kernel and thus require recompiling everytime the 
> > > ABI
> > > J> changes, but it is useful to have them.  Please restore those.
> > > 
> > > I have very much anticipated this comment from you, John.
> > > 
> > > I would like to remind you, that we have had this very exact conversation
> > > back when I removed kvm support from netstat/route.c. Let me search the
> > > archives:
> > > 
> > > https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> > > 
> > > This conversation has had a continuation on IRC, which I don't archive.
> > > 
> > > AFAIR, first I told that with all my involvement into networking stack,
> > > I never ever had experienced a need to run route stats on a core. The
> > > debugger were the only useful tool. And that opinion was seconded by
> > > other network hackers. Then we discussed that a proper tool chould use
> > > dynamic type parsing and not kvm(3). You said that future gdb has python
> > > scripting and that would work fine. Meanwhile, you insisted that I restore
> > > the functionality. I resisted to put kvm(3) back into netstat/route.c, and
> > > instead I created a gdb script that prints exactly what 'nestat -anr -M 
> > > cor
> > e'
> > > prints. And I committed the script just to satisfy your demand:
> > > 
> > > tools/debugscripts/netstat-anr.gdb
> > > 
> > > Can you please fairly answer, have you (or anyone else) ever used the
> > > script during these 2 years?
> > > 
> > > I believe, the inpcb/tcpcb printing from a core functionality has the
> > > same level of real usefulness. I could create the same script for pcbs,
> > > and I am afraid it is going to share fate of netstat-anr.gdb.
> > 
> > How long run this script for core file w/ 40K TCP connections?
> 
> Would it be possible to replace this script with new DTrace probes and a 
> DTrace script?

DTrace probes in /etc/rc.d/savecore? Realy?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Slawa Olhovchenkov]

On Tue, Mar 21, 2017 at 11:50:04AM -0700, Gleb Smirnoff wrote:

>   John,
> 
> On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
> J> First, this is a very good change and long overdue in divorcing the
> J> user-facing structure for live system reporting vs the kernel structure.
> J> 
> J> However, I realize you don't use info from netstat when debugging kernel
> J> crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
> J> require a matching kernel and thus require recompiling everytime the ABI
> J> changes, but it is useful to have them.  Please restore those.
> 
> I have very much anticipated this comment from you, John.
> 
> I would like to remind you, that we have had this very exact conversation
> back when I removed kvm support from netstat/route.c. Let me search the
> archives:
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> 
> This conversation has had a continuation on IRC, which I don't archive.
> 
> AFAIR, first I told that with all my involvement into networking stack,
> I never ever had experienced a need to run route stats on a core. The
> debugger were the only useful tool. And that opinion was seconded by
> other network hackers. Then we discussed that a proper tool chould use
> dynamic type parsing and not kvm(3). You said that future gdb has python
> scripting and that would work fine. Meanwhile, you insisted that I restore
> the functionality. I resisted to put kvm(3) back into netstat/route.c, and
> instead I created a gdb script that prints exactly what 'nestat -anr -M core'
> prints. And I committed the script just to satisfy your demand:
> 
> tools/debugscripts/netstat-anr.gdb
> 
> Can you please fairly answer, have you (or anyone else) ever used the
> script during these 2 years?
> 
> I believe, the inpcb/tcpcb printing from a core functionality has the
> same level of real usefulness. I could create the same script for pcbs,
> and I am afraid it is going to share fate of netstat-anr.gdb.

How long run this script for core file w/ 40K TCP connections?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Gleb Smirnoff]

  John,

On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
J> First, this is a very good change and long overdue in divorcing the
J> user-facing structure for live system reporting vs the kernel structure.
J> 
J> However, I realize you don't use info from netstat when debugging kernel
J> crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
J> require a matching kernel and thus require recompiling everytime the ABI
J> changes, but it is useful to have them.  Please restore those.

I have very much anticipated this comment from you, John.

I would like to remind you, that we have had this very exact conversation
back when I removed kvm support from netstat/route.c. Let me search the
archives:

https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html

This conversation has had a continuation on IRC, which I don't archive.

AFAIR, first I told that with all my involvement into networking stack,
I never ever had experienced a need to run route stats on a core. The
debugger were the only useful tool. And that opinion was seconded by
other network hackers. Then we discussed that a proper tool chould use
dynamic type parsing and not kvm(3). You said that future gdb has python
scripting and that would work fine. Meanwhile, you insisted that I restore
the functionality. I resisted to put kvm(3) back into netstat/route.c, and
instead I created a gdb script that prints exactly what 'nestat -anr -M core'
prints. And I committed the script just to satisfy your demand:

tools/debugscripts/netstat-anr.gdb

Can you please fairly answer, have you (or anyone else) ever used the
script during these 2 years?

I believe, the inpcb/tcpcb printing from a core functionality has the
same level of real usefulness. I could create the same script for pcbs,
and I am afraid it is going to share fate of netstat-anr.gdb.

Today, I can actually bring yet another point on kvm(3) in netstat,
which I didn't bring in 2015. Now netstat is dependent on libxo, which
has a lot of complex things in it and was never reviewed wrt security
implications. Now netstat has only one last bit of kvm functionality
remaining - UNIX pcbs printing, which also has close to zero level
of usefulness. Once we remove it, we can remove setgid bit and kmem
access from /usr/bin/netstat and sleep better.

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[John Baldwin]

On Tuesday, March 21, 2017 06:39:49 AM Gleb Smirnoff wrote:
> Author: glebius
> Date: Tue Mar 21 06:39:49 2017
> New Revision: 315662
> URL: https://svnweb.freebsd.org/changeset/base/315662
> 
> Log:
>   Hide struct inpcb, struct tcpcb from the userland.
>   
>   This is a painful change, but it is needed.  On the one hand, we avoid
>   modifying them, and this slows down some ideas, on the other hand we still
>   eventually modify them and tools like netstat(1) never work on next version 
> of
>   FreeBSD.  We maintain a ton of spares in them, and we already got some ifdef
>   hell at the end of tcpcb.
>   
>   Details:
>   - Hide struct inpcb, struct tcpcb under _KERNEL || _WANT_FOO.
>   - Make struct xinpcb, struct xtcpcb pure API structures, not including
> kernel structures inpcb and tcpcb inside.  Export into these structures
> the fields from inpcb and tcpcb that are known to be used, and put there
> a ton of spare space.
>   - Make kernel and userland utilities compilable after these changes.
>   - Bump __FreeBSD_version.
>   
>   Reviewed by:rrs, gnn
>   Differential Revision:  D10018

First, this is a very good change and long overdue in divorcing the
user-facing structure for live system reporting vs the kernel structure.

However, I realize you don't use info from netstat when debugging kernel
crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
require a matching kernel and thus require recompiling everytime the ABI
changes, but it is useful to have them.  Please restore those.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Ronald Klop]

On Tue, 21 Mar 2017 10:19:24 +0100, Mathieu Arnold  wrote:


Le 21/03/2017 à 08:27, Gleb Smirnoff a écrit :

On Tue, Mar 21, 2017 at 08:22:19AM +0100, Baptiste Daroussin wrote:
B> On Mon, Mar 20, 2017 at 11:54:33PM -0700, Gleb Smirnoff wrote:
B> > On Tue, Mar 21, 2017 at 07:50:32AM +0100, Antoine Brodin wrote:
B> > A> >   This change is known to break a ton of ports. More than 100  
if
B> > A> > counting depends. I'm sorry for that and I already started to  
fix

B> > A> > them.
B> > A> >
B> > A> > Please send all new breakages to me.
B> > A>
B> > A> Hi,
B> > A>
B> > A> Exp-runs should happen before breakage happens, not after.
B> > A> If you already know that it breaks hundreds of ports, please  
revert

B> > A> and request an exp-run.
B> >
B> > The exp-run has already been made:
B> >
B> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210673
B> >
B> > Wasn't very helpful.
B> >
B>
B> I disagree it was useful it showed you some ports that were breaking  
given there
B> was some high level one you were expected to provide patches to fix  
them.


I'm working on them right now.


You should have worked on it *before* the patch breaking everything
landed, providing patches for the ports that were reported as broken,
and repeat until all the ports that were building before were building
again.

You should **not** have committed the patch to the src tree before all
those patches were created, and you should have committed all the
patches at once, preferably before committing the patch to the src tree.






People should...
No ports are broken on released version of FreeBSD. The broken ones are  
being fixed.
And a very good improvement of code has happened. Maybe a notice in  
UPDATING helps third-party people.

I don't see a real problem. Only progress.

Ronald.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Mathieu Arnold]

Le 21/03/2017 à 08:27, Gleb Smirnoff a écrit :
> On Tue, Mar 21, 2017 at 08:22:19AM +0100, Baptiste Daroussin wrote:
> B> On Mon, Mar 20, 2017 at 11:54:33PM -0700, Gleb Smirnoff wrote:
> B> > On Tue, Mar 21, 2017 at 07:50:32AM +0100, Antoine Brodin wrote:
> B> > A> >   This change is known to break a ton of ports. More than 100 if
> B> > A> > counting depends. I'm sorry for that and I already started to fix
> B> > A> > them.
> B> > A> >
> B> > A> > Please send all new breakages to me.
> B> > A> 
> B> > A> Hi,
> B> > A> 
> B> > A> Exp-runs should happen before breakage happens, not after.
> B> > A> If you already know that it breaks hundreds of ports, please revert
> B> > A> and request an exp-run.
> B> > 
> B> > The exp-run has already been made:
> B> > 
> B> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210673
> B> > 
> B> > Wasn't very helpful.
> B> > 
> B> 
> B> I disagree it was useful it showed you some ports that were breaking given 
> there
> B> was some high level one you were expected to provide patches to fix them.
>
> I'm working on them right now.

You should have worked on it *before* the patch breaking everything
landed, providing patches for the ports that were reported as broken,
and repeat until all the ports that were building before were building
again.

You should **not** have committed the patch to the src tree before all
those patches were created, and you should have committed all the
patches at once, preferably before committing the patch to the src tree.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Gleb Smirnoff]

  Ngie,

On Tue, Mar 21, 2017 at 01:42:44AM -0700, Ngie Cooper (yaneurabeya) wrote:
N>  This change broke the sdp module: 
https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/2294/console .
N> Thanks,
N> -Ngie

Thanks for heads up. Fixed.

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Ngie Cooper (yaneurabeya)]

> On Mar 21, 2017, at 01:42, Ngie Cooper (yaneurabeya)  
> wrote:
> 
>> 
>> On Mar 20, 2017, at 23:39, Gleb Smirnoff  wrote:
>> 
>> Author: glebius
>> Date: Tue Mar 21 06:39:49 2017
>> New Revision: 315662
>> URL: https://svnweb.freebsd.org/changeset/base/315662
>> 
>> Log:
>> Hide struct inpcb, struct tcpcb from the userland.
>> 
>> This is a painful change, but it is needed.  On the one hand, we avoid
>> modifying them, and this slows down some ideas, on the other hand we still
>> eventually modify them and tools like netstat(1) never work on next version 
>> of
>> FreeBSD.  We maintain a ton of spares in them, and we already got some ifdef
>> hell at the end of tcpcb.
>> 
>> Details:
>> - Hide struct inpcb, struct tcpcb under _KERNEL || _WANT_FOO.
>> - Make struct xinpcb, struct xtcpcb pure API structures, not including
>>   kernel structures inpcb and tcpcb inside.  Export into these structures
>>   the fields from inpcb and tcpcb that are known to be used, and put there
>>   a ton of spare space.
>> - Make kernel and userland utilities compilable after these changes.
>> - Bump __FreeBSD_version.
>> 
>> Reviewed by: rrs, gnn
>> Differential Revision:   D10018
> 
>   This change broke the sdp module: 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/2294/console .
> Thanks,
> -Ngie

It also broke gcc buildworld: 
https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/47/console .
Thanks,
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Ngie Cooper (yaneurabeya)]

> On Mar 20, 2017, at 23:39, Gleb Smirnoff  wrote:
> 
> Author: glebius
> Date: Tue Mar 21 06:39:49 2017
> New Revision: 315662
> URL: https://svnweb.freebsd.org/changeset/base/315662
> 
> Log:
>  Hide struct inpcb, struct tcpcb from the userland.
> 
>  This is a painful change, but it is needed.  On the one hand, we avoid
>  modifying them, and this slows down some ideas, on the other hand we still
>  eventually modify them and tools like netstat(1) never work on next version 
> of
>  FreeBSD.  We maintain a ton of spares in them, and we already got some ifdef
>  hell at the end of tcpcb.
> 
>  Details:
>  - Hide struct inpcb, struct tcpcb under _KERNEL || _WANT_FOO.
>  - Make struct xinpcb, struct xtcpcb pure API structures, not including
>kernel structures inpcb and tcpcb inside.  Export into these structures
>the fields from inpcb and tcpcb that are known to be used, and put there
>a ton of spare space.
>  - Make kernel and userland utilities compilable after these changes.
>  - Bump __FreeBSD_version.
> 
>  Reviewed by: rrs, gnn
>  Differential Revision:   D10018

This change broke the sdp module: 
https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/2294/console .
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Gleb Smirnoff]

On Tue, Mar 21, 2017 at 08:22:19AM +0100, Baptiste Daroussin wrote:
B> On Mon, Mar 20, 2017 at 11:54:33PM -0700, Gleb Smirnoff wrote:
B> > On Tue, Mar 21, 2017 at 07:50:32AM +0100, Antoine Brodin wrote:
B> > A> >   This change is known to break a ton of ports. More than 100 if
B> > A> > counting depends. I'm sorry for that and I already started to fix
B> > A> > them.
B> > A> >
B> > A> > Please send all new breakages to me.
B> > A> 
B> > A> Hi,
B> > A> 
B> > A> Exp-runs should happen before breakage happens, not after.
B> > A> If you already know that it breaks hundreds of ports, please revert
B> > A> and request an exp-run.
B> > 
B> > The exp-run has already been made:
B> > 
B> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210673
B> > 
B> > Wasn't very helpful.
B> > 
B> 
B> I disagree it was useful it showed you some ports that were breaking given 
there
B> was some high level one you were expected to provide patches to fix them.

I'm working on them right now.

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Baptiste Daroussin]

On Mon, Mar 20, 2017 at 11:54:33PM -0700, Gleb Smirnoff wrote:
> On Tue, Mar 21, 2017 at 07:50:32AM +0100, Antoine Brodin wrote:
> A> >   This change is known to break a ton of ports. More than 100 if
> A> > counting depends. I'm sorry for that and I already started to fix
> A> > them.
> A> >
> A> > Please send all new breakages to me.
> A> 
> A> Hi,
> A> 
> A> Exp-runs should happen before breakage happens, not after.
> A> If you already know that it breaks hundreds of ports, please revert
> A> and request an exp-run.
> 
> The exp-run has already been made:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210673
> 
> Wasn't very helpful.
> 

I disagree it was useful it showed you some ports that were breaking given there
was some high level one you were expected to provide patches to fix them.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Gleb Smirnoff]

On Tue, Mar 21, 2017 at 07:50:32AM +0100, Antoine Brodin wrote:
A> >   This change is known to break a ton of ports. More than 100 if
A> > counting depends. I'm sorry for that and I already started to fix
A> > them.
A> >
A> > Please send all new breakages to me.
A> 
A> Hi,
A> 
A> Exp-runs should happen before breakage happens, not after.
A> If you already know that it breaks hundreds of ports, please revert
A> and request an exp-run.

The exp-run has already been made:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210673

Wasn't very helpful.

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Antoine Brodin]

On Tue, Mar 21, 2017 at 7:41 AM, Gleb Smirnoff  wrote:
>   Hi!
>
>   This change is known to break a ton of ports. More than 100 if
> counting depends. I'm sorry for that and I already started to fix
> them.
>
> Please send all new breakages to me.

Hi,

Exp-runs should happen before breakage happens, not after.
If you already know that it breaks hundreds of ports, please revert
and request an exp-run.

Antoine  (with hat: portmgr)


> On Tue, Mar 21, 2017 at 06:39:49AM +, Gleb Smirnoff wrote:
> T> Author: glebius
> T> Date: Tue Mar 21 06:39:49 2017
> T> New Revision: 315662
> T> URL: https://svnweb.freebsd.org/changeset/base/315662
> T>
> T> Log:
> T>   Hide struct inpcb, struct tcpcb from the userland.
> T>
> T>   This is a painful change, but it is needed.  On the one hand, we avoid
> T>   modifying them, and this slows down some ideas, on the other hand we 
> still
> T>   eventually modify them and tools like netstat(1) never work on next 
> version of
> T>   FreeBSD.  We maintain a ton of spares in them, and we already got some 
> ifdef
> T>   hell at the end of tcpcb.
> T>
> T>   Details:
> T>   - Hide struct inpcb, struct tcpcb under _KERNEL || _WANT_FOO.
> T>   - Make struct xinpcb, struct xtcpcb pure API structures, not including
> T> kernel structures inpcb and tcpcb inside.  Export into these structures
> T> the fields from inpcb and tcpcb that are known to be used, and put 
> there
> T> a ton of spare space.
> T>   - Make kernel and userland utilities compilable after these changes.
> T>   - Bump __FreeBSD_version.
> T>
> T>   Reviewed by:   rrs, gnn
> T>   Differential Revision: D10018
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Gleb Smirnoff]

  Hi!

  This change is known to break a ton of ports. More than 100 if
counting depends. I'm sorry for that and I already started to fix
them.

Please send all new breakages to me.

On Tue, Mar 21, 2017 at 06:39:49AM +, Gleb Smirnoff wrote:
T> Author: glebius
T> Date: Tue Mar 21 06:39:49 2017
T> New Revision: 315662
T> URL: https://svnweb.freebsd.org/changeset/base/315662
T> 
T> Log:
T>   Hide struct inpcb, struct tcpcb from the userland.
T>   
T>   This is a painful change, but it is needed.  On the one hand, we avoid
T>   modifying them, and this slows down some ideas, on the other hand we still
T>   eventually modify them and tools like netstat(1) never work on next 
version of
T>   FreeBSD.  We maintain a ton of spares in them, and we already got some 
ifdef
T>   hell at the end of tcpcb.
T>   
T>   Details:
T>   - Hide struct inpcb, struct tcpcb under _KERNEL || _WANT_FOO.
T>   - Make struct xinpcb, struct xtcpcb pure API structures, not including
T> kernel structures inpcb and tcpcb inside.  Export into these structures
T> the fields from inpcb and tcpcb that are known to be used, and put there
T> a ton of spare space.
T>   - Make kernel and userland utilities compilable after these changes.
T>   - Bump __FreeBSD_version.
T>   
T>   Reviewed by:   rrs, gnn
T>   Differential Revision: D10018
T> 
T> Modified:
T>   head/contrib/bsnmp/snmp_mibII/mibII_tcp.c
T>   head/contrib/bsnmp/snmp_mibII/mibII_udp.c
T>   head/contrib/ipfilter/ipsend/sock.c
T>   head/lib/libprocstat/libprocstat.c
T>   head/sys/netinet/in_pcb.c
T>   head/sys/netinet/in_pcb.h
T>   head/sys/netinet/ip_divert.c
T>   head/sys/netinet/raw_ip.c
T>   head/sys/netinet/tcp_subr.c
T>   head/sys/netinet/tcp_syncache.c
T>   head/sys/netinet/tcp_timer.c
T>   head/sys/netinet/tcp_timer.h
T>   head/sys/netinet/tcp_var.h
T>   head/sys/netinet/udp_usrreq.c
T>   head/sys/sys/param.h
T>   head/usr.bin/netstat/inet.c
T>   head/usr.bin/sockstat/sockstat.c
T>   head/usr.bin/systat/extern.h
T>   head/usr.bin/systat/netcmds.c
T>   head/usr.bin/systat/netstat.c
T>   head/usr.sbin/tcpdrop/tcpdrop.c
T>   head/usr.sbin/trpt/trpt.c
T> 
T> Modified: head/contrib/bsnmp/snmp_mibII/mibII_tcp.c
T> 
==
T> --- head/contrib/bsnmp/snmp_mibII/mibII_tcp.cTue Mar 21 05:15:10 
2017(r315661)
T> +++ head/contrib/bsnmp/snmp_mibII/mibII_tcp.cTue Mar 21 06:39:49 
2017(r315662)
T> @@ -310,7 +310,7 @@ op_tcpconn(struct snmp_context *ctx __un
T>  switch (value->var.subs[sub - 1]) {
T>  
T>case LEAF_tcpConnState:
T> -switch (tcpoids[i].tp->xt_tp.t_state) {
T> +switch (tcpoids[i].tp->t_state) {
T>  
T>case TCPS_CLOSED:
T>  value->v.integer = 1;
T> 
T> Modified: head/contrib/bsnmp/snmp_mibII/mibII_udp.c
T> 
==
T> --- head/contrib/bsnmp/snmp_mibII/mibII_udp.cTue Mar 21 05:15:10 
2017(r315661)
T> +++ head/contrib/bsnmp/snmp_mibII/mibII_udp.cTue Mar 21 06:39:49 
2017(r315662)
T> @@ -105,8 +105,8 @@ fetch_udp(void)
T>   ptr->xig_len > sizeof(struct xinpgen);
T>   ptr = (struct xinpgen *)(void *)((char *)ptr + ptr->xig_len)) {
T>  inp = (struct xinpcb *)ptr;
T> -if (inp->xi_inp.inp_gencnt > xinpgen->xig_gen ||
T> -(inp->xi_inp.inp_vflag & INP_IPV4) == 0)
T> +if (inp->inp_gencnt > xinpgen->xig_gen ||
T> +(inp->inp_vflag & INP_IPV4) == 0)
T>  continue;
T>  
T>  udp_total++;
T> @@ -128,17 +128,17 @@ fetch_udp(void)
T>   ptr->xig_len > sizeof(struct xinpgen);
T>   ptr = (struct xinpgen *)(void *)((char *)ptr + ptr->xig_len)) {
T>  inp = (struct xinpcb *)ptr;
T> -if (inp->xi_inp.inp_gencnt > xinpgen->xig_gen ||
T> -(inp->xi_inp.inp_vflag & INP_IPV4) == 0)
T> +if (inp->inp_gencnt > xinpgen->xig_gen ||
T> +(inp->inp_vflag & INP_IPV4) == 0)
T>  continue;
T>  oid->inp = inp;
T>  oid->index.len = 5;
T> -inaddr = ntohl(inp->xi_inp.inp_laddr.s_addr);
T> +inaddr = ntohl(inp->inp_laddr.s_addr);
T>  oid->index.subs[0] = (inaddr >> 24) & 0xff;
T>  oid->index.subs[1] = (inaddr >> 16) & 0xff;
T>  oid->index.subs[2] = (inaddr >>  8) & 0xff;
T>  oid->index.subs[3] = (inaddr >>  0) & 0xff;
T> -oid->index.subs[4] = ntohs(inp->xi_inp.inp_lport);
T> +oid->index.subs[4] = ntohs(inp->inp_lport);
T>  oid++;
T>  }
T>  
T> 
T> Modified: head/contrib/ipfilter/ipsend/sock.c
T> 
==
T> --- head/contrib/ipfilter/ipsend/sock.c  Tue Mar 21 05:15:10 2017
(r315661)
T> +++ 

svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Gleb Smirnoff]

Author: glebius
Date: Tue Mar 21 06:39:49 2017
New Revision: 315662
URL: https://svnweb.freebsd.org/changeset/base/315662

Log:
  Hide struct inpcb, struct tcpcb from the userland.
  
  This is a painful change, but it is needed.  On the one hand, we avoid
  modifying them, and this slows down some ideas, on the other hand we still
  eventually modify them and tools like netstat(1) never work on next version of
  FreeBSD.  We maintain a ton of spares in them, and we already got some ifdef
  hell at the end of tcpcb.
  
  Details:
  - Hide struct inpcb, struct tcpcb under _KERNEL || _WANT_FOO.
  - Make struct xinpcb, struct xtcpcb pure API structures, not including
kernel structures inpcb and tcpcb inside.  Export into these structures
the fields from inpcb and tcpcb that are known to be used, and put there
a ton of spare space.
  - Make kernel and userland utilities compilable after these changes.
  - Bump __FreeBSD_version.
  
  Reviewed by:  rrs, gnn
  Differential Revision:D10018

Modified:
  head/contrib/bsnmp/snmp_mibII/mibII_tcp.c
  head/contrib/bsnmp/snmp_mibII/mibII_udp.c
  head/contrib/ipfilter/ipsend/sock.c
  head/lib/libprocstat/libprocstat.c
  head/sys/netinet/in_pcb.c
  head/sys/netinet/in_pcb.h
  head/sys/netinet/ip_divert.c
  head/sys/netinet/raw_ip.c
  head/sys/netinet/tcp_subr.c
  head/sys/netinet/tcp_syncache.c
  head/sys/netinet/tcp_timer.c
  head/sys/netinet/tcp_timer.h
  head/sys/netinet/tcp_var.h
  head/sys/netinet/udp_usrreq.c
  head/sys/sys/param.h
  head/usr.bin/netstat/inet.c
  head/usr.bin/sockstat/sockstat.c
  head/usr.bin/systat/extern.h
  head/usr.bin/systat/netcmds.c
  head/usr.bin/systat/netstat.c
  head/usr.sbin/tcpdrop/tcpdrop.c
  head/usr.sbin/trpt/trpt.c

Modified: head/contrib/bsnmp/snmp_mibII/mibII_tcp.c
==
--- head/contrib/bsnmp/snmp_mibII/mibII_tcp.c   Tue Mar 21 05:15:10 2017
(r315661)
+++ head/contrib/bsnmp/snmp_mibII/mibII_tcp.c   Tue Mar 21 06:39:49 2017
(r315662)
@@ -310,7 +310,7 @@ op_tcpconn(struct snmp_context *ctx __un
switch (value->var.subs[sub - 1]) {
 
  case LEAF_tcpConnState:
-   switch (tcpoids[i].tp->xt_tp.t_state) {
+   switch (tcpoids[i].tp->t_state) {
 
  case TCPS_CLOSED:
value->v.integer = 1;

Modified: head/contrib/bsnmp/snmp_mibII/mibII_udp.c
==
--- head/contrib/bsnmp/snmp_mibII/mibII_udp.c   Tue Mar 21 05:15:10 2017
(r315661)
+++ head/contrib/bsnmp/snmp_mibII/mibII_udp.c   Tue Mar 21 06:39:49 2017
(r315662)
@@ -105,8 +105,8 @@ fetch_udp(void)
 ptr->xig_len > sizeof(struct xinpgen);
  ptr = (struct xinpgen *)(void *)((char *)ptr + ptr->xig_len)) {
inp = (struct xinpcb *)ptr;
-   if (inp->xi_inp.inp_gencnt > xinpgen->xig_gen ||
-   (inp->xi_inp.inp_vflag & INP_IPV4) == 0)
+   if (inp->inp_gencnt > xinpgen->xig_gen ||
+   (inp->inp_vflag & INP_IPV4) == 0)
continue;
 
udp_total++;
@@ -128,17 +128,17 @@ fetch_udp(void)
 ptr->xig_len > sizeof(struct xinpgen);
  ptr = (struct xinpgen *)(void *)((char *)ptr + ptr->xig_len)) {
inp = (struct xinpcb *)ptr;
-   if (inp->xi_inp.inp_gencnt > xinpgen->xig_gen ||
-   (inp->xi_inp.inp_vflag & INP_IPV4) == 0)
+   if (inp->inp_gencnt > xinpgen->xig_gen ||
+   (inp->inp_vflag & INP_IPV4) == 0)
continue;
oid->inp = inp;
oid->index.len = 5;
-   inaddr = ntohl(inp->xi_inp.inp_laddr.s_addr);
+   inaddr = ntohl(inp->inp_laddr.s_addr);
oid->index.subs[0] = (inaddr >> 24) & 0xff;
oid->index.subs[1] = (inaddr >> 16) & 0xff;
oid->index.subs[2] = (inaddr >>  8) & 0xff;
oid->index.subs[3] = (inaddr >>  0) & 0xff;
-   oid->index.subs[4] = ntohs(inp->xi_inp.inp_lport);
+   oid->index.subs[4] = ntohs(inp->inp_lport);
oid++;
}
 

Modified: head/contrib/ipfilter/ipsend/sock.c
==
--- head/contrib/ipfilter/ipsend/sock.c Tue Mar 21 05:15:10 2017
(r315661)
+++ head/contrib/ipfilter/ipsend/sock.c Tue Mar 21 06:39:49 2017
(r315662)
@@ -78,8 +78,10 @@ typedef int boolean_t;
 # include 
 #endif
 #include 
+#define_WANT_INPCB
 #include 
 #include 
+#define_WANT_TCPCB
 #include 
 #include 
 #include 

Modified: head/lib/libprocstat/libprocstat.c
==
--- head/lib/libprocstat/libprocstat.c  Tue Mar 21 05:15:10 2017
(r315661)
+++