John, On Wed, Apr 08, 2015 at 12:24:48PM -0400, John Baldwin wrote: J> On Tuesday, April 07, 2015 05:50:46 AM Gleb Smirnoff wrote: J> > Author: glebius J> > Date: Tue Apr 7 05:50:45 2015 J> > New Revision: 281188 J> > URL: https://svnweb.freebsd.org/changeset/base/281188 J> > J> > Log: J> > Like it was already done for 'netstat -i', drop the kvm(3) support J> > in 'netstat -r'. J> > J> > The netstat/route.c was the last abuser of struct ifnet and struct J> > rtentry in the tree. With this change if_var.h can become kernel J> > only include, _WANT_RTENTRY can go away and projects/ifnet and J> > projects/routing can go forward. J> > J> > Differential Revision: https://reviews.freebsd.org/D2242 J> > Reviewed by: melifaro, gnn J> > Sponsored by: Nginx, Inc. J> > Sponsored by: Netflix J> J> This breaks netstat -r on a crashdump. Just because you don't find this J> information useful during post-mortem debugging doesn't mean that other folks J> do not. The easiest solution is to update crashinfo to remove the netstat J> commands it runs.
I do analyze cores often, and always find gdb the only useful tool. My opinion is seconded by melifaro@, who was quite a lot into the routing debugging for the last years. I will update crashinfo. J> However, I don't understand the fear that system binaries can peek inside J> the kernel for debugging info. It's ok for it to be a fragile ABI that J> isn't exposed to normal applications and to require people to keep a matching J> netstat with their kernel (along with the other tools crashinfo calls). Just J> update the code in netstat to cope with the new data structures. That should J> be much easier to test than having to convert N device drivers. You mentioned only the smallest problem - the need to routinely update the netstat, as the fragile ABI changes. But there are two more problems: 1) If userland application knows kernel structures, then we can not merge to stable/X changes that change these structures. For example, since netstat in stable/10 still uses kvm(3), we can't merge r256525 and r262763, which improve performance and make counters precise. Yes, exactly the counters that netstat is meant to report. We can't fix the netstat output due to netstat! 2) If we expose kernel structures to userland, people would write code that use them. And the code won't go into src/tools only, it will also go into ports. Albeit we have a stable API to read interface addresses and counters, in the ports there were 15 applications, that were based on copy-paste from netstat/if.c, using kvm(3) instead of API. And I had to fix them all. Finally, when we start to expose kernel structures to userland this leads to endless header dependencies, and may yield in expose all policy, but usually yields in dirty hacks like hiding second half of a structure under #ifdef _KERNEL. -- Totus tuus, Glebius. _______________________________________________ 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"
