From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 11:19:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6448316A4CE for ; Wed, 14 Jan 2004 11:19:57 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D937C43D68 for ; Wed, 14 Jan 2004 11:19:53 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0EJICUd050740; Wed, 14 Jan 2004 14:18:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0EJICTh050737; Wed, 14 Jan 2004 14:18:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Jan 2004 14:18:12 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ryan Beasley In-Reply-To: <20040114185636.GA60885@uberhacker.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: p_[usi]ticks from userland without kvm and procfs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 19:19:57 -0000 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