Date: Thu, 19 Dec 2013 18:14:01 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, "Alexander V. Chernikov" <melifaro@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org> Subject: Re: svn commit: r259562 - head/usr.bin/netstat Message-ID: <20131220021401.GX99167@funkthat.com> In-Reply-To: <20131220002849.GH71033@FreeBSD.org> References: <201312181825.rBIIPR25014515@svn.freebsd.org> <201312181640.52147.jhb@freebsd.org> <20131219115735.GN29088@FreeBSD.org> <201312191552.04202.jhb@freebsd.org> <20131220002849.GH71033@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131220021401.GX99167>