Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jan 2004 14:18:12 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        Ryan Beasley <ryanb@goddamnbastard.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: p_[usi]ticks from userland without kvm and procfs?
Message-ID:  <Pine.NEB.3.96L.1040114141229.49872D-100000@fledge.watson.org>
In-Reply-To: <20040114185636.GA60885@uberhacker.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 14 Jan 2004, Ryan Beasley wrote:

> I'm poring over some code that uses the p_[usi]ticks counters inside of
> struct proc.  This is fine under 4.x where kinfo_proc includes a copy of
> proc, but is broken under 5.x since a commit 3 years ago that
> reorganized kinfo_proc. 
> 
> So, outside of kvm and procfs, is there any user<->kernel interface for
> getting to struct proc or just those counters?  (getrusage is kinda
> close except one can't lookup info about another process.  :|. ) 

libkvm uses two back-ends to retrieve information from the kernel: it can
either retrieve it using sysctl() on a live kernel, or using kvm access on
/dev/kmem or a core file.  Generally, using sysctl() is preferred for a
live kernel, as it requires no special privilege, and also lets the kernel
decide what data is revealed to the user application (i.e., hide processes
owned by other users).  The kernel function that generally exports process
information userspace access is sysctl_out_proc() in
src/sys/kern/kern_proc.c, which calls kill_info_proc() of
fill_kinfo_thread(), depending on a flag passed to sysctl. 

Those fields are now part of the thread definition as opposed to the proc
definition, and don't appear in the externalized structure in -current
(that I can tell).  A lot of process accounting and measurement changed
with the introduction of M:N threads (KSE), and some of the details
haven't yet been sorted out as part of the dust settling.  It could well
be that the fields are not currently maintained properly, and that the
functionality in the kernel needs to be fixed to measure them again
properly. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Senior Research Scientist, McAfee Research




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040114141229.49872D-100000>