From owner-svn-src-head@FreeBSD.ORG Fri Dec 20 02:14:03 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89D0DA50; Fri, 20 Dec 2013 02:14:03 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 440441F68; Fri, 20 Dec 2013 02:14:02 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rBK2E1NH051428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 18:14:02 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rBK2E1It051427; Thu, 19 Dec 2013 18:14:01 -0800 (PST) (envelope-from jmg) Date: Thu, 19 Dec 2013 18:14:01 -0800 From: John-Mark Gurney To: Gleb Smirnoff Subject: Re: svn commit: r259562 - head/usr.bin/netstat Message-ID: <20131220021401.GX99167@funkthat.com> References: <201312181825.rBIIPR25014515@svn.freebsd.org> <201312181640.52147.jhb@freebsd.org> <20131219115735.GN29088@FreeBSD.org> <201312191552.04202.jhb@freebsd.org> <20131220002849.GH71033@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131220002849.GH71033@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 19 Dec 2013 18:14:02 -0800 (PST) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, "Alexander V. Chernikov" , John Baldwin X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 02:14:03 -0000 Gleb Smirnoff wrote this message on Fri, Dec 20, 2013 at 04:28 +0400: > 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. So, CTF contains all the type information necessary and the members of the struct... For example: ctfdump -t /boot/kernel/kernel contains: <919> POINTER (anon) refers to 1556 [...] [1377] POINTER (anon) refers to 919 [1378] STRUCT (anon) (16 bytes) le_next type=919 off=0 le_prev type=1377 off=64 [...] <1556> STRUCT proc (1208 bytes) p_list type=1378 off=0 [...] So, we can now, assuming we don't repurpose field names, have a "copy kernel struct to userland struct" function that uses CTF to make the proper mappings... Obviously if userland has a field that is missing in the kernel or vise versa, or size/type doesn't match, then some handling will be needed, but for the most part we could ignore the new fields as that's often what the tools have to do when we change a padded field to not be padding... The interesting thing about this also is that it would mean we could also remove the need for padding, since the CTF would describe the struct size, etc. I have not looked at the internals of CTF, so I don't know how easy it would be to just extract the parts that we need for the struct, or if we'd need a sysctl to fetch all CTF data, or fetch it from the kernel.. Having the data split may be better so the kernel wouldn't have to fetch it all out each time, etc, plus it could be cached in the library... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."