From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 21 00:38:57 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5858516A417; Wed, 21 Nov 2007 00:38:57 +0000 (UTC) (envelope-from skip@menantico.com) Received: from vms169133pub.verizon.net (vms169133pub.verizon.net [206.46.169.133]) by mx1.freebsd.org (Postfix) with ESMTP id 4285313C447; Wed, 21 Nov 2007 00:38:57 +0000 (UTC) (envelope-from skip@menantico.com) Received: from mx.menantico.com ([71.188.11.206]) by vms169133.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JRT00FR0Z47PKWL@vms169133.mailsrvcs.net>; Tue, 20 Nov 2007 18:38:32 -0600 (CST) Date: Tue, 20 Nov 2007 19:41:18 -0500 From: Skip Ford In-reply-to: <20071119115508.M59049@fledge.watson.org> To: Robert Watson Mail-followup-to: Robert Watson , "Bjoern A. Zeeb" , Yuri , freebsd-hackers@FreeBSD.org Message-id: <20071121004118.GA16878@menantico.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <20071114132743.GB835@menantico.com> <20071116144356.S10677@fledge.watson.org> <20071116212342.GD835@menantico.com> <20071117215003.U53707@maildrop.int.zabbadoz.net> <20071117223910.GD813@menantico.com> <20071118151712.GA21185@voi.aagh.net> <20071118204743.GE813@menantico.com> <20071118205541.U97497@fledge.watson.org> <20071118221317.GF813@menantico.com> <20071119115508.M59049@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: "Bjoern A. Zeeb" , freebsd-hackers@FreeBSD.org, Yuri Subject: Re: How to get filename of an open file descriptor X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 00:38:57 -0000 Robert Watson wrote: > The main missing feature right now, from my perspective, is signal > information, but are there other pieces of detailed process information we > could usefully be displaying? I'm not sure I want to get into teaching > procinfo about generating stack traces, which is something the Solaris > tools can do, but perhaps there are other things we could be displaying. The functionality I'd use most if implemented would be process trees. But, I wouldn't really call it a missing feature since we already have parent pids in ps(1). I'm not so sure generating a tree is something your tool should do either. A lot of OSes seem to have such a tool, but I don't know if they provide more information than we could put together just using ps(1) and your tool once committed. Think I'll play around with creating a kern.proc.tree, just to see if I can, so a tool could dump it with a few lines, but I think it doesn't belong. > Although it occurs to me that, in many ways, it would be nice to be able to > generate a kernel stack trace for each user thread--often when debugging a > hung process, that's one of the pieces of information I'd really like to > have, as just seeing a generic wchan sleep on a lock is not very useful. That would be invaluable, and isn't functionality we can gain currently by scripting other tools. -- Skip