John, On Thu, Dec 19, 2013 at 03:52:03PM -0500, John Baldwin wrote: J> > J> Please don't gratuitiously break things that /usr/sbin/crashinfo runs. It's J> > J> fine if kvm mode is fragile and requires the binary to be in sync with the J> > J> kernel and is only used for crash dumps, but it is very useful to extract J> > J> all sorts of info out of a crash dump. J> > J> > The problem is that these tools (netstat, and some others) prevent us from J> > improving the kernel network stack. We can't make improvements that are J> > mergeable to stable/x branch, since the tools would be broken. J> J> No, I explicitly said "it's fine if the kvm mode is fragile and requires the J> binary to be in sync and is only used for crash dumps". That means it's J> fine to merge changes as long as you merge the whole thing together. It also J> means you don't have to support all possible internal kernel ABIs in a branch.
Sorry but this is not true. Yeah, I'm grateful that you personally allow me to break ABIs, but the general FreeBSD project policy doesn't allow that anymore in stable branches. I don't have strong opinion on this, I really think that running kernel and world out of sync is a bad idea, so I may agree with you. But the project as a whole have established a policy that within a stable branch newer kernel can run tools from x.0-RELEASE. And agree or not, I abide. J> > Moreover J> > any improvement in head/, requires from developer additional work in netstat J> > code, which I must admit isn't a pleasure to work with. J> J> Well, yes, there all sorts of things like, say, documentation that one has to J> do beyond the original hacking in order to make a logical change more complete. J> Plus, if you think writing netstat stuff in C is bad, try writing the equivalent J> in kgdb scripts instead (which is what you'd need to do to provide equivalent J> functionality) Actually I do that often, and find it easier to make kgdb scripts. J> > I agree that usage of tools on vmcores is useful. But we all should agree that J> > it has very limited use. Only kernel hackers and developers are expected to J> > do this. J> J> If users enable crashinfo then they all run this for each crash, so not just J> developers. Having worked in an environment with hundreds of crashes per day, J> having some post-processed output to dig through rather than firing up kgdb J> every time is quite valuable. I've fixed quite a lot of PRs in network stack and never payed attention to the routing table or ifnet stats provided by netstat in that long submissions attached to PRs. As said, w/o addresses this output is quite useless for debugging. J> > My suggestion is that all this code is deleted from src/usr.bin/netstat, and J> > moved to src/tools, and we relax assertion that src/tools must be compatible J> > with any kernel within the branch. So, any person who wants this functionality, J> > needs to keep his src/tools in sync with kernel and compile a tool when he J> > desires to dump routing table from a vmcore. J> J> That is mostly what I suggested in terms of not having the same ABI guarantees, J> but I still want crashinfo to provide a comprehensive set of details to developers J> so that users can just mail that file to a developer without having to be walked J> through intricate gdb gymnastics. Good, then this stuff just needs to migrate to a special crashdump tool. And probably its output shouldn't resemble netstat(1), since there is no reason for that. Perfectly if structures are just dumped as a whole. Yeah, here gdb scripting comes into mind. J> > Finally, when we remove all the kvm(3) usage from a tool, then we can remove J> > the sugid bit from it, which would be a another fine point. J> J> That is 100% irrelevant to crash dumps. I only ask that the KVM mode needs J> to work for crash dumps. I am more than happy for all "live" access to use J> sysctls instead of kvm and to not need the set-gid bit as a result. Looks like we are coming to agreement. The way to go is to remove kvm access from netstat, substituting it with proper APIs. The better crashdump utility needs to be started. Not yet sure that C + kvm(3) is a proper framework for it. I don't understand the plan with dtrace based tool well, but reading John-Marks' email I find it interesting. gdb scripting is also an option. -- 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"
