Date: Tue, 20 Nov 2007 19:41:18 -0500 From: Skip Ford <skip@menantico.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-hackers@FreeBSD.org, Yuri <yuri@rawbw.com> Subject: Re: How to get filename of an open file descriptor Message-ID: <20071121004118.GA16878@menantico.com> In-Reply-To: <20071119115508.M59049@fledge.watson.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071121004118.GA16878>